Comment by lvh | Hacker News Reader

Comment by lvh | Hacker News Reader

Noise is a fantastic set of protocols for building modern cryptographic applications. Here are a few things to look out for:

- The interactions in the protocol are precisely specified

- The exact security properties of the different interactions are precisely specified, including in-depth concepts like the AKE's KCI properties (AKE: authenticated key exchange, KCI: key compromise impersonation, where post-compromise, an attacker can impersonate anyone to the victim, instead of being able to just impersonate the victim to anyone).

- Several mutually compatible reference implementations.

As great as it is, most applications should still rely on TLS for transport security. Noise is primarily for places where TLS' properties aren't suitable.

Another interesting tidbit that might not be obvious: like TLS, Noise is one protocol with many instantiations. Because it builds on a few simple primitives, these can be swapped out, although Noise defines sane defaults. However, an application built on top of Noise is far more likely to have one fixed ciphersuite set (agility, but not negotiation) -- so it wouldn't be unreasonable to think of Noise as a blueprint for a set of protocols.

I'd be happy to answer any detailed questions about the Noise protocol; I am a cryptographer, but I've had nothing to do with its development.

What are the sorts of things (that aren't secure messaging) for which Noise-based solutions might be suitable and for which TLS isn't?

Actually a tough question and getting tougher with TLS 1.3: if you can use Noise, you can also configure TLS down to a reasonable configuration that uses only solid primitives and doesn't rely on the TLS PKI. The answer is probably: you should use TLS, and if you're in a place where you really should consider something like Noise or Noise Pipes, you'll probably know it.

The place where it really starts to make sense to think about Noise is when you're already committed to doing a custom protocol. Jason Donenfeld's Wireguard is a great example: a fresh protocol makes a lot of sense for a new VPN transport.

Ironically, in the context of a secure messenger, the Noise/TLS distinction isn't really important at all. The important cryptography in an E2E-secure messenger happens at a layer higher than the transport itself.

Later

Spitballed this question on crypto dork Slack and there is a use case with a clear answer: if you're doing a datagram transport rather than TCP streams, Noise is probably always a clear win. DTLS is a mess.

From that slack convo, I disagreed. DTLS specifies everything for UDP: what happens if you receive messages out of order? or if the datagram length is not enough for a message? or if you drop messages? or if someone actively MITM you (easy in UDP)? DTLS specifies all these things. Noise doesn't. It's up to you to find out a way to make it work for UDP. Not that Noise specifies how to implement it on top of TCP, but it's more straight-forward there.

I was also told that Wireguard uses Noise on top of UDP, so it would be interesting to see what they did there.

Another good point for Noise: if you're planning to implement a TLS-like protocol from scratch, I would go for Noise instead of TLS. It's just simpler, lighter and easy to customize to your own needs.

Indeed DTLS is a "pipe", whereas pure Noise isn't, and pure Noise doesn't have any DoS protection, which DTLS does.

But indeed DTLS is a mess for other reasons.

For WireGuard I use Noise with stronger DoS resistance and anti replay measures than DTLS, custom tailored for being a layer 3 tunnel. Details here: https://www.wireguard.io/papers/wireguard.pdf

> if someone actively MITM you (easy in UDP)

In what way is MITM easier in UDP than TCP? Assuming you use similar techniques to verify your connection, I can't see a difference.

You don't need to do anything to pretend you are the source address. Whereas in TCP you need to guess some random seq number.

But if you're using encryption anyways, you're probably using some sort of "sign this challenge" message to verify the user instead, which would verify that that IP received the challenge anyways.

There is a phase where you're not using encryption: the handshake phase.

Yep, thanks, I think I actually misunderstood the 'framework' level range of Noise (I thought you could 'easily' make Signal out of Noise). There's a video on their wiki that's also a good summary of what it's about.

https://www.youtube.com/watch?v=ceGTgqypwnQ

What about Noise vs QUIC? Which should end up getting adopted?

You can't really "adopt" Noise; it's a metaprotocol. You instantiate it for different applications. The ideas from Noise should probably filter into every secure transport.

Noise is a blueprint for building a protocol, so they're not quite the same kind of thing. If you think you'd want QUIC, you probably want TLS instead. Noise is for more bespoke applications that have a good reason why TLS can't be their transport protocol; I don't think it should generally be the first port of call for most applications.

Reply on news.ycombinator.com