On Thu, Apr 07, 2011 at 05:18:12PM -0400, Nick Mathewson wrote: > 8) This is totally back-of-the-envelope stuff, but it might be a good > starting point for crypto discussion. > > Here's a first cut of what I think might go in an improved RSA handshake: > > * First 8 bytes of the SHA256 hash of the onion key [8 bytes] > (This is here so that onion key rotation can work without having > to sometimes try the wrong onion key incorrectly.) > * PK-encrypted: > * Padding [PK_PAD_LEN bytes] > * SHA256 hash of all remaining fields. [32 bytes] > * Symmetric key seed [16 bytes] > * The first part of g^x. [as much will fit in the PK-encrypted portion] > * Symmetrically encrypted: > * The rest of g^x. > * 0 bytes for padding. > > Here's a first cut of what I think might go in a hypothetical > diffie-hellman based handshake, for use with something like > Curve25519. (I'm using g^x and g^y notation here as if this were > diffie-hellman in Z_p, since I don't yet trust myself to write ECC > stuff correctly. I'm assuming that the node's public onion key is > g^x.) > > * SHA256 of all remaining fields. [32 bytes] > * First 8 bytes of the SHA256 hash of the onion key (8 bytes) > * g^y1 [DH_LEN bytes] > * Encrypted using a symmetric key based on g^(x*y1): > * g^y2 [DH_LEN bytes] > * 0 bytes for padding
The phrase that jumps to mind is, "Danger Will Robinson!". ;-) If we're redesigning the AKE (authenticated key agreement) bits, we probably shouldn't just make up our own stuff. - Ian _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
