5 ms·

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

by lvh 10y ago

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.

mtgx 10y ago
What about Noise vs QUIC? Which should end up getting adopted?
- tptacek 10y ago
  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.
- lvh 10y ago
  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.
pvg 10y ago
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?
- tptacek 10y ago
  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.
  - baby 10y ago
    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.
    - zx2c4 10y ago
      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 https://www.wireguard.io/papers/wireguard.pdf

by lvh 10y ago

mtgx 10y ago

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

tptacek 10y ago
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.
lvh 10y ago
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.

pvg 10y ago

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?

tptacek 10y ago
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.
- baby 10y ago
  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.
  - zx2c4 10y ago
    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 https://www.wireguard.io/papers/wireguard.pdf