On Fri, Oct 14, 2016 at 2:45 PM, isis agora lovecruft
<i...@torproject.org> wrote:
> After discussion with John Schanck and Trevor Perrin over the last month,
> we've decided to make some alterations to the specification for hybrid
> handshakes in Tor proposal #269.
> It seems that John, Trevor, and I are mostly in agreement about most
> of the construction.

Hi Isis, all,

My main suggestion was to take a look at Noise:


Noise is a framework for DH-based (Ntor-like) key exchange protocols.
You choose a "handshake pattern" plus your favorite crypto and it
fills in the details.  So this would save you from hand-crafting your
key derivation and transcript hashing, as Noise specifies this (e.g.
it uses a chain of HKDF for key derivation, similar to Signal, IPsec,
or TLS 1.3).

For Ntor + hybrid forward secrecy, you could choose something like:


The names are a mouthful, but specify the whole protocol:

  NKhfs is a handshake pattern
    NK = (N)o client long-term key, (K)nown server long-term key
    hfs = hybrid forward secrecy
  25519+NewHope = public-key algorithms
  ChaChaPoly = ChaCha20/Poly1305 for AEAD
  SHA256 = hash for transcript hashing and HKDF

Some other benefits:

 * There are C and Java libraries that can implement this (with
NewHope) by Rhys Weatherley, and hopefully more will pop up.

 * Saves design effort, because it's easy to change patterns to add
client auth, or pre-shared keys, or certificates; or swap out crypto).

 * Also used by WhatsApp and WireGuard, so hopefully the libraries,
tools, and design will continue to improve, benefiting other users.

Noise can be hard to figure out because it's a toolkit, not a single
protocol, but I'd be happy to answer questions about particular use

Of course, I also think Tor's existing Ntor, the current Tor
proposals, and the changes Isis is mentioning, all seem fine.

tor-dev mailing list

Reply via email to