[tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519
dgoulet at ev0ke.net
Thu Nov 17 16:52:10 UTC 2016
On 15 Nov (16:29:33), George Kadianakis wrote:
> Nick Mathewson <nickm at torproject.org> writes:
> > [ text/plain ]
> > Hi! I thought I'd write this up while it was fresh in my mind. It
> > could be used as an alternative method to the current proposed client
> > authentication mechanism. We could implement both, or just this, or
> > just the other.
> > My description here will be a bit terser than we'd want in a proper
> > proposal, but I wanted to share it.
> > This design is based on George Kadianakis's client authentication
> > design; it won't make sense unless you've read it.
> > =============
> > Let every client generate a curve25519 keypair, and tell the hidden
> > service operator about the public key. This keypair takes the place
> > of the long-term shared secret. For some client C, denote the secret
> > key as x_X and the public key as X_C.
> > For every descriptor, the hidden service generates a fresh keypair <y,
> > Y>, and includes Y in the the outer encrypted layer.
> > Now, for each client, the hidden service computes curve25519(X_C, y)
> > and uses this as the input for two KDF functions. Call these outputs
> > K1_C and K2_C. The hidden service generates an auth-client line for
> > each client as follows:
> > "auth-client" SP client-id SP encrypted-cookie
> > This is the same as in George's proposal, except that client-id is
> > derived from a truncated version of K1_C, and the encrypted-cookie
> > portion is encrypted based on K2_C.
> > When the client receives the descriptor, it decrypts the outer layer,
> > then sees the value of Y that the hidden server advertised. It
> > computes curve25519(Y, x_c), and derives K1_C and K2_C. It uses K1_C
> > to find the appropriate entry on the list, and then uses K2_C to
> > decrypt it and find the descriptor cookie.
> > =============
> > Advantages:
> > * managing public keys can be easier than managing shared secrets.
> > * The encoding is slightly shorter, since no IV is needed, since K2
> > is different every time.
> > * probably others?
> > Disadvantages:
> > * Curve25519 costs more computationally than non-public-key operations
> > * probably others?
> I worked some more on prop224 client authorization. I have a draft
> torspec patch at prop224_client_auth_3 in my repo:
I personally like this very much. Apart from minor syntax issues and spacing,
I think this scheme is getting to a point where it's simple and efficient.
I think the introduce auth section (INTRO-AUTH) needs to be edited more though
because we are still mentionning password and ed25519 authentication but I
understand that waiting until we all agree on the client auth mechanism is
> I ended up using the x25519 scheme described above by Nick.
> I also ended up dodging the UX questions raised on this thread, by only
> specifying the Tor protocol level details, and leaving the out-of-band
> HS<->client protocol mostly unspecified. I believe that this out-of-band
> protocol and configuration details can be figured out in the future, and
> we should not block on them right now.
Yes, I believe this is fine. Note that tor-keygen tool is getting another
_very_ important use case here that is the key generation on client side.
> I also added some more high-level details on client auth in the intro
> section, which should be useful to people who read the proposal for the
> first time.
> In the appendix, I added a section with some rough ideas on how the
> torrc configuration could work, and how a control port interface could
> work. This is just a sketch so far, and we can get more specific as we
> get closer to implementation fot this feature.
Looks good to me. The naming will _most_ probably change as we already have
those names in torrc with a different API but the format to me is simple and
easy to use.
And the control port commands are _very_ important as it would allow TBB to
easily add client auth with some UI instead of hot hacking torrc file. And
this would be a giant step foward in usability of client auth.
> Finally, I've been assuming AES128 for the STREAM() cipher so that the
> size computations performed earlier on this thread are still
> accurate. If we want to pump it to AES256, the IVs and the descriptor
> cookie ciphertexts will double in size for each authorized client. If we
> actually want to go with AES256, we need to peform new computations
> about the padding and max descriptor size. If you people like the rest
> of the patch here, I can do the calculations again.
Which might also change our maximum size of 40k we put there.
One note. I haven't seen a maximum value of client we allow. Did I miss it or
it's also maybe too early to put there as we are still discussing the
specifics. Which makes me think that maybe that 40k limit is also a bit
arbitrary for now based on that.
Thanks for the great work!
> tor-dev mailing list
> tor-dev at lists.torproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 585 bytes
Desc: not available
More information about the tor-dev