[tor-dev] Improved circuit-setup protocol [was: Re: Designing and implementing improved circuit-setup protocol [was: GSoC 2011]]

[Nick Mathewson]

On Thu, Mar 31, 2011 at 5:52 AM, Robert Ransom <rransom.8774 at 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,
-- 
Nick