On Thu, Apr 07, 2011 at 05:18:12PM -0400, Nick Mathewson wrote:
- 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