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