On 15 Nov (16:29:33), George Kadianakis wrote:
Nick Mathewson nickm@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_...
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev