> On 24 Nov. 2016, at 10:56, s7r <[email protected]> wrote: > > > teor wrote: >> >>> >>> Very good. We can add a new torrc option for ed25519 key based >>> authentication for clients (v3) so the current >>> HiddenServiceAuthorizeClient (v2) will not break old torrc's until >>> everyone upgrades. >>> >>> However, we could just add an auth-type value after >>> HiddenServiceAuthorizeClient that will only work for v3. For example: >>> >>> HiddenServiceAuthorizeClient pubkey client-name,client-name,client-name,... >>> >>> It's obvious where 'pubkey' comes from, but it can be changed to >>> anything. This way we preserve the option that it's already common for >>> users (HiddenServiceAuthorizeClient), we maintain compatibility of >>> torrcs during transition period and also have the same option in the >>> future when we are fully migrated to v3. >>> >>> This is perfectly fine, since we do not use any auth method that works >>> on v2 to v3 (which I am also super happy with). We also don't restrict >>> ourselves from the possibility to add new auth-types for v3 in the >>> future, should we need them. >> >> This means that people who upgrade to v3 services will need to >> redistribute all their client auth keys. This could be a lot of work, >> particularly if the out-of-band channel is manual, or there are a >> large number of users. >> >> Here's an alternative proposal: >> >> Tor accepts v2 HiddenServiceAuthorizeClient and HidServAuth for v3 >> services, then feeds the auth-cookie into a key derivation function to >> produce an ed25519 private key. This key is used for authentication as >> specified. >> > This is not specified anywhere until now, my suggestion was based on the > current form of the proposals. For v3 we only use ed25519 key based > authentication, and if we use: > > HiddenServiceAuthroizeClient pubkey client1,client2 > > Tor will use this only for v3 of course, while: > > HiddenServiceAuthorizeClient basic client1,client2 will only be used for v2. > > If an user upgrades to v3, it has no other but to generate the new > authentication credentials (keys) for clients, regardless of the torrc > option we use. > >> I don't think this is worth the extra coding effort - I think we are >> better to focus on getting people to upgrade, and designing the new >> options to be easy to use. >> >> But I could be convinced if a hidden service operator who uses client >> authentication says it would take a lot of effort to re-issue client >> keys. >> > > No, no, it is not worth it *at all*. The biggest headache is in > distributing the private keys out of band to authorized clients
Which my proposal avoids, by re-using the v2 keys for v3 services. > , not > their generation (generation is done by Tor automatically, in few > seconds, based on just one line with the client names). And we have no > way to skip the distribution phase, better focus to make the key > management as simple as possible rather than coding a derivation > function that (maybe) provides a false sense of security if the > passphrases have low entropy. The v3 keys derived from the existing v2 keys would have the same entropy as those keys: 16 bytes (REND_DESC_COOKIE_LEN). Yes, this is inferior to the ~31 bytes of entropy in an ed25519 key. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------ _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
