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

[George Kadianakis <desnacked@xxxxxxxxxx>]

Nick Mathewson <nickm@xxxxxxxxxxxxxx> 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 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.

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.

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. 

Cheers!
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev