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

[Ian Goldberg]

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