On 12 Jul (20:24:54), George Kadianakis wrote: > David Goulet <dgoulet@xxxxxxxxxxxxxx> writes: > > > On 18 May (19:03:09), George Kadianakis wrote: > >> Ian Goldberg <iang@xxxxxxxxxxxxxxx> writes: > >> > >> > On Thu, May 10, 2018 at 12:20:05AM +0700, Suphanat Chunhapanya wrote: > >> >> On 05/09/2018 03:50 PM, George Kadianakis wrote: > >> >> > b) We might also want to look into XEdDSA and see if we can potentially > >> >> > use the same keypair for both intro auth (ed25519) and desc auth > >> >> (x25519). > >> >> > >> >> This will be a great advantage if we can do that because putting two > >> >> private keys in the HidServAuth is so frustrating. > >> > > >> > The private key for intro auth is used to make a signature (that will be > >> > different per client), while the private key for desc auth is used to > >> > decrypt the descriptor (which will be the same for all clients), no? > >> > > >> > >> Hm. Both intro auth and desc auth keys are different for each client. In > >> the case of desc auth we do that so that we can revoke a client without > >> needing to refresh desc auth keys for all other clients. > > > > Following yesterday's discussion on IRC with haxxpop and asn, and some more > > today, I worked on a revised version of the spec: > > > > https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket20700_01 > > > > Probably will be easier to just read the whole thing instead of the diff: > > > > https://gitweb.torproject.org/user/dgoulet/torspec.git/tree/rend-spec-v3.txt?h=ticket20700_01#n2279 > > > > So the idea is that instead of making the HS client/operator have to pass > > around portions of a file containing private and public keys, it is to > > logically seperate them so that the operator only deals with one single file > > when wanting to transmit the keys to a client. > > > > Thanks for the fixes David. > > Please see last commit of https://github.com/torproject/torspec/pull/24 > for some stuff on top of your branch. > > Some things we need to think about: > - The ".pubkeys" files are now used internally by Tor, whereas the > "./client_cfg_lines" file is the one that the operator is supposed to > look at and interact with. Is it easier for the operator to deal with > one big file, or with many small files? We should think about that and > maybe reverse our choices. Single file might actually be better for the client_cfg_lines because 1) it is much easier to shred out of the filesystem, 2) it is also much easier to spot by the operator that she still has private keys from client(s) instead of having to look constantly into client_cfg_lines for leftover lines. > > As an example, how is the operator supposed to know which line in > "./client_cfg_lines" is for which client? In my patch above I used > # comments to separate lines but that might not be straightforward for > people. > > - Assuming that we are not doing intro auth any time soon, I deleted all > mentions of ed25519 keys from that side of the spec, in the assumption > that we will need to introduce them back the right way if we ever > decide to do intro auth. Is this a good idea or not? > > As an example of the complexity I'm trying to hide, if we keep ed25519 > in the spec, we need to specify how the HidServAuth line knows whether > a key is x25519 or ed25519. Actually, we should have a simple format like "ed25519:<base64_key>" instead so then in 5 years, if we end up with 10 different authorization method, we can just pass "key:value" argument at will to the torrc option. > > - Do we need to define new torrc options for service-side and client-side? So far, only client side needs a new "HidServAuth". > > Some more things to do: > - Rename "./client_authorized" to "./authorized_clients"? +1 > - Rename "./client_cfg_lines" to ???? Lets go single file! I actually now prefer single file. > - What's the "auth-type"? I assume standard. We could use "descriptor" even though it won't stay much to a regular user, it will at least have a semantic for power users. Because even "standard" for regular user will probably mean nothing... ? David -- fbv5H3G6O9hLu6Txl6sNIg/unJ95a7iOi43Afzw8ROs=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev