On 15 Nov (16:29:33), George Kadianakis wrote: > 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 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@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev