On 05/09/2018 03:50 PM, George Kadianakis wrote:
I thought about this some more and discussed it with haxxpop on IRC. In the end, I think that perhaps starting with just desc auth and then in the future implementing intro auth is also an acceptable plan forward.
I think we have two more things to think about.
1. I forgot to think about the format of client_authorized_pubkeys file. In the client_authorized_pubkeys file, each line should indicate the auth type for which the pubkey is used instead of just specifying the client name and the pubkey. So the line should be as follows.
<client-name> <auth-type> <pubkey>
and, if auth-type is "standard", it will be equivalent to two lines of "desc" and "intro".
2. If we want to release the "desc" auth first, I want to say something about the config lines.
The "standard" auth config on the client side will not contain the ed25519 private key and it will look like this:
HidServAuth onion-address standard x25519-private-key
However, after we release the intro auth, that config line (which does not contain the ed25519 private key) should still be valid because, if the client upgrades its version, it doesn't need to change the word "standard" to the word "desc" in the HidServAuth config line.
On the service side, it will be different. After releasing "desc" auth but before releasing "intro" auth, the line in client_authorized_pubkeys will look like this (without ed25519 pubkey).
<client-name> standard x25519-public-key
But after we release the "intro" auth, that line shouldn't be valid anymore because the "standard" line should contain both x25519 and ed25519 public keys. It's different from the client side.
--
I think (1) may not have problems (I guess) but for (2) is it acceptable to make ed25519-private-key optional on the HidServAuth "standard" config line?
--
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.