[tor-dev] HS v3 client authorization types

Suphanat Chunhapanya haxx.pop at gmail.com
Wed May 9 17:20:05 UTC 2018

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

This will be a great advantage if we can do that because putting two
private keys in the HidServAuth is so frustrating.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180510/8017adaa/attachment-0001.sig>

More information about the tor-dev mailing list