On Fri, Oct 14, 2016 at 2:45 PM, isis agora lovecruft isis@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:
Noise_NKhfs_25519+NewHope_ChaChaPoly_SHA256 or: Noise_NKhfs_25519+NTRU_AESGCM_BLAKE2b etc.
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 cases.
Of course, I also think Tor's existing Ntor, the current Tor proposals, and the changes Isis is mentioning, all seem fine.
Trevor