On 24 Nov. 2016, at 10:56, s7r s7r@sky-ip.org 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