[tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519

[David Goulet]

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?
> >
> >
> 
> Hello,
> 
> I worked some more on prop224 client authorization. I have a draft
> torspec patch at prop224_client_auth_3 in my repo:
>     https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=prop224_client_auth_3

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
wise.

> 
> 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!
David

> 
> Cheers!
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161117/bdcb57bc/attachment.sig>