On Thu, Mar 31, 2011 at 5:52 AM, Robert Ransom rransom.8774@gmail.com wrote:
Hi! I'm going to wait on a full review of your create/extend proposal till it's done, but I though I could potentially answer some questions and offer some comments:
1) I think CREATE cells need to get a field asking for a specific way of handling RELAY cells. If we ever update the relay crypto (that is, the stuff described in 5.5 and 6.1 today) to do something other than AES128_CTR for the encryption, SHA1 for the digest, we'll need a way to ask for it. I suppose that we could do that via adding a new handshake type for a new desired link protocol, but it seems like the two could be more or less orthogonal.
2) I don't get the rationale behind the variable-length type names. Elsewhere in our protocol we'd just use a 1- or 2-byte type field. Do we win a lot by letting these be longer?
3) By convention, everything in our protocol is in "network" (big-endian) byte-order.
4) There needs to be an authenticated way for the client to know which handshake types and link specifier types a given node supports. This could be as simple as a series of statements like "Tor versions xyz and later will support handshake type Y", or as complex as advertising them in router descriptors.
5) I like the idea of separating the link specifiers from the handshake type in EXTENDED cells.
6) I also think it'd be smart to figure out the actual link specifier and handshake types that we want to move to before we decide that we are confident that this format is right. Those can be a different proposal, though.
7) Here's a first cut of what I think might go in a link specifier format:
* V4Address -- an ipv4 address, set to 0 if there is no IPv4 address for the node [4 bytes] * V4ORPort [2 bytes] * V6Address -- an ipv6 address, set to 0 if there is no IPv6 address for the node [16 bytes] * V6ORPort [2 bytes] * SHA256 of RSA1024 identity key [32 bytes]
When we decide what longer identity keys should look like, we can add a new link specifier format that supports those.
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
In both cases, we'll want a new key derivation function.
yrs,