Noise Protocol Framework(noiseprotocol.org)
noiseprotocol.org
Noise Protocol Framework
https://noiseprotocol.org/
13 comments
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.
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.
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
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.
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.
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
https://www.youtube.com/watch?v=ceGTgqypwnQ
What about Noise vs QUIC? Which should end up getting adopted?
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.
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 great protocol. It used to actually be only one protocol (when it was first being worked out a few years ago), and I implemented a very shitty version of it then. Since then, it's now evolved to be a set of protocols, and it's much more robust now. (You should be able to rewind the git history and see what changed.)
I've been thinking of trying my hand at something like writing a new implementation of the modern protocol, but I have no need for a truly general one supporting every agreement/primitive set, since I'd rather just implement one, exact Noise protocol. Plus, it'd probably be easier to wait for TLS 1.3 to hit libressl and just use libtls, then. Maybe one day, though...
EDIT: Actually, I remember at one point, I had a early version of the original Noise protocol called "TweetNoise" that I tried to fit into 100 tweets, based on TweetNacl. That was fun. I think I got it finished but never released it. Unfortunately my laptop with the SSD holding that code had its fan die after Christmas, so I can't be sure until next week.
If anyone would like to still do this with the new noise, it'd probably be fun. :)
I've been thinking of trying my hand at something like writing a new implementation of the modern protocol, but I have no need for a truly general one supporting every agreement/primitive set, since I'd rather just implement one, exact Noise protocol. Plus, it'd probably be easier to wait for TLS 1.3 to hit libressl and just use libtls, then. Maybe one day, though...
EDIT: Actually, I remember at one point, I had a early version of the original Noise protocol called "TweetNoise" that I tried to fit into 100 tweets, based on TweetNacl. That was fun. I think I got it finished but never released it. Unfortunately my laptop with the SSD holding that code had its fan die after Christmas, so I can't be sure until next week.
If anyone would like to still do this with the new noise, it'd probably be fun. :)
If you want to see Noise in action, applied to a real protocol, check out Wireguard: https://www.wireguard.io/protocol/
I wrote WireGuard. Happy to answer any questions.
https://www.wireguard.io/papers/wireguard.pdf
That paper has a bit more in depth elaboration, if you're interested.
https://www.wireguard.io/papers/wireguard.pdf
That paper has a bit more in depth elaboration, if you're interested.
Looks awesome! Do you have any plans for GUI apps?
I don't intend to write these, but I know that people are working on things like plugins for Network Manager, which has a GUI, so I think a GUI-able WireGuard will be a reality at some point.
I also have an Android client written but still private, which I suppose constitutes a GUI.
So: the future will probably include clicks and swipes!
I also have an Android client written but still private, which I suppose constitutes a GUI.
So: the future will probably include clicks and swipes!
So if I understand correctly, this is a framework to design your own secure protocol for your applications?
Kind of a higher-level building block instead of working directly with NaCL and such?
If I'm missing something, can someone explain it to me please?
Kind of a higher-level building block instead of working directly with NaCL and such?
If I'm missing something, can someone explain it to me please?
Yes. There are a few "layers" of crypto in most modern applications:
- Low-level primitives, like AES, ChaCha20.
- Usefully combined primitives, like AES-OCB, NaCl secretbox...
- High-level protocols like TLS and Noise.
- (sometimes) crypto spoken over the encrypted protocols, often for E2E crypto e.g. GPG over SMTPS, or CloudFlare blinded CAPTCHA tokens over HTTPS
This matters because people sometimes think that they're not doing homebrew crypto because they are using e.g. AES. Noise builds on many of the things available in libsodium, including Curve25519 DH, ChaCha20, BLAKE2 et cetera.
- Low-level primitives, like AES, ChaCha20.
- Usefully combined primitives, like AES-OCB, NaCl secretbox...
- High-level protocols like TLS and Noise.
- (sometimes) crypto spoken over the encrypted protocols, often for E2E crypto e.g. GPG over SMTPS, or CloudFlare blinded CAPTCHA tokens over HTTPS
This matters because people sometimes think that they're not doing homebrew crypto because they are using e.g. AES. Noise builds on many of the things available in libsodium, including Curve25519 DH, ChaCha20, BLAKE2 et cetera.
Is Noise the right answer to any of these crypto "questions"? https://news.ycombinator.com/item?id=9593916
Not yet. It will be the best answer to the last of those questions, and it is a great case study for how the preceding questions are best answered. (Those questions, by the way, originally come from Colin Percival; I didn't choose them, and wouldn't say they're the best questions).
What we're waiting for is good Noise-primitive implementations in enough languages. The Noise protocols themselves are probably the best secure channel protocols we're going to get for awhile.
What we're waiting for is good Noise-primitive implementations in enough languages. The Noise protocols themselves are probably the best secure channel protocols we're going to get for awhile.
Generally speaking: they're not the same kind of thing, and no. For two reasons: most of these recommendations are at a lower level; they talk about primitives, not about protocols. Secondly, most applications still want TLS, probably with limited ciphersuite support, although you could do a lot worse than Noise. TLS is much better understood, and better supported. Noise is great if you care about implementing protocols with new properties, like indistinguishability, or over novel transports, or denaibility, or...
Aha.
Awesome! thanks for the answers everyone. This looks very interesting.
However... I guess the "don't roll your own cryptography" still applies for this? I mean, I know better than trying to "design" my own algorithms. I even know that I shouldn't try to implement anything below what NaCL provides.
But how about this? Could I use this to deploy my own secure protocol for my own projects?
Obviously I have no formal cryptography training so I'm leaning towards "no, you are not qualified to implement anything", but just out of curiosity, is there some point at which we can build something securely without the need to either outsource this to a security team or getting actual training on security stuff?
Or, put in another way, what amount of security training/knowledge should I have to properly use this while avoiding doing something universally stupid? is it still "you need to be actually trained for this" or is it enough to have some idea and being able to follow some best practices?
Awesome! thanks for the answers everyone. This looks very interesting.
However... I guess the "don't roll your own cryptography" still applies for this? I mean, I know better than trying to "design" my own algorithms. I even know that I shouldn't try to implement anything below what NaCL provides.
But how about this? Could I use this to deploy my own secure protocol for my own projects?
Obviously I have no formal cryptography training so I'm leaning towards "no, you are not qualified to implement anything", but just out of curiosity, is there some point at which we can build something securely without the need to either outsource this to a security team or getting actual training on security stuff?
Or, put in another way, what amount of security training/knowledge should I have to properly use this while avoiding doing something universally stupid? is it still "you need to be actually trained for this" or is it enough to have some idea and being able to follow some best practices?
Well, this is where it gets tricky. Higher-and-higher level tools like libsodium and now Noise keep propelling us forward, making it easier and easier to design applications that use cryptography.
I think one of the biggest challenges we have remaining is two-fold: appropriately communicate the tradeoffs between different options (e.g. repudiation vs non-repudiation, post-quantum secure KEX vs regular KEX, fast symmetric nonce-using crypto vs nonce-misuse resistant crypto, et cetera), and making alien technology (SNARKs, MPC...) more approachable.
For most applications, you probably still want TLS instead of Noise. But if you want Noise, you really, really, really want Noise. If for some reason it is necessary to set up a tunnel with a pre-shared key, for example, I'd probably suggest you use one of Noise's PSK modes over TLS.
So, it still depends what you're doing. But noise implementations and "toolkits" bring us closer to a future where applications for which TLS isn't appropriate have a decent chance at a secure protocol too.
I think one of the biggest challenges we have remaining is two-fold: appropriately communicate the tradeoffs between different options (e.g. repudiation vs non-repudiation, post-quantum secure KEX vs regular KEX, fast symmetric nonce-using crypto vs nonce-misuse resistant crypto, et cetera), and making alien technology (SNARKs, MPC...) more approachable.
For most applications, you probably still want TLS instead of Noise. But if you want Noise, you really, really, really want Noise. If for some reason it is necessary to set up a tunnel with a pre-shared key, for example, I'd probably suggest you use one of Noise's PSK modes over TLS.
So, it still depends what you're doing. But noise implementations and "toolkits" bring us closer to a future where applications for which TLS isn't appropriate have a decent chance at a secure protocol too.
Don't know whether you had a chance to read the Noise Protocol Specification available on the site yet. If not please read chapter 14 (Rationale). The information is very valuable even if you don't use Noise specifically. I found that and Chapter 13 (Security Considerations) very useful in general.
I've been working on a secure UDP file transfer protocol recently and this was of particular interest to me because I ended up using many of the same design choices. At the same time, my implementation ends up being simpler since I limit the types of digests and ciphers used. It really goes to show you how difficult it is to create a general protocol that allows for massive flexibility while keeping it secure.
Noise is a blueprint for a lot of concrete protocols, mostly in the way that TLS has many ciphersuites. While most TLS implementations need to speak most ciphersuites in order to be useful, Noise applications are typically bespoke, so applications using Noise will typically also limit themselves to one ciphersuite and one Noise mode, e.g. Noise_IK_448_ChaChaPoly_BLAKE2b.
I'm excited see things like this because there are a lot of applications now starting to use homebrew crypto protocols and not all of them follow good design practices to mitigate even common pitfalls in something like a key exchange (despite using vetted libraries for crypto primitives). Having good, vetted patterns like Noise that cover key exchange and authentication should help improve the security of a lot of these applications.
Out of interest, how do you verify the similar design choices? For example, how do you check that, say, your AKE is KCI-secure?
By keeping it simple and sticking with proven building blocks and patterns so as to not "roll my own crypto" (which is very, very bad).
If you're using something like AES in GCM mode and ECDHE the only part where you have some leeway in implementation is in how you exchange the ephemeral keys. I largely get around this because both clients and servers are required to have valid X509 certificates and the protocol won't proceed if they can't mutually authenticate. You can use these certificates to sign the preliminary messages (selecting ciphers, digests, and protocol specific parameters) until the key exchange is complete and you're encrypting everything with the ephemeral keys. At that point, even if the static keys are compromised you still get PFS.
You can also mitigate things like KCI MITM attacks by simply forcing strong cipher suites and key derivation protocols. AES-128-GCM and AES-256-GCM when used with ephemeral ECDH (using the right curves) is very well studied and known to provide PFS among other things.
If you're using something like AES in GCM mode and ECDHE the only part where you have some leeway in implementation is in how you exchange the ephemeral keys. I largely get around this because both clients and servers are required to have valid X509 certificates and the protocol won't proceed if they can't mutually authenticate. You can use these certificates to sign the preliminary messages (selecting ciphers, digests, and protocol specific parameters) until the key exchange is complete and you're encrypting everything with the ephemeral keys. At that point, even if the static keys are compromised you still get PFS.
You can also mitigate things like KCI MITM attacks by simply forcing strong cipher suites and key derivation protocols. AES-128-GCM and AES-256-GCM when used with ephemeral ECDH (using the right curves) is very well studied and known to provide PFS among other things.
One of the things I feel are underrated here, is that this spec ships with implementations written by different people in different languages.
The fact these are interoperable confirms they meet the spec.
Contrast to Argon2, where recent independent implementations found the reference implementation was incorrect.
The fact these are interoperable confirms they meet the spec.
Contrast to Argon2, where recent independent implementations found the reference implementation was incorrect.
I come late but there is a video explaining the basics of the Noise Protocol Framework here: https://www.youtube.com/watch?v=ceGTgqypwnQ
Would a implementation in Erlang be useful?
I wonder how a language/platform like Erlang/Beam VM, with its 100s of thousands/millions of concurrent processes can be utilized for speeding up deciphering/key search operations.
The math operations for each process would have to be made really fast using C libraries or custom assembly code.
Other concurrent languages/libraries would offer the same benefits I suppose.
I guess the same question can be asked of operations on current generation of GPUs.
The math operations for each process would have to be made really fast using C libraries or custom assembly code.
Other concurrent languages/libraries would offer the same benefits I suppose.
I guess the same question can be asked of operations on current generation of GPUs.
For computation-bound processes, having more than one thread per CPU just means you pay task-switching fees unnecessarily.
In fact, "I'm just starting with Erlang/Haskell/Go and I wanted to play with parallelization so I took the first 100 million integers and spawned a thread to add each individual pair together in a distributed fashion and it's ten thousand times slower than just using a C loop, WTF?" is a very popular post on the relevant language forums. In that situation what happens is because the "payload" of each thread is a single machine-language instruction (give or take loading and saving to memory), all you see is the overhead of starting, stopping, and joining threads. (Or processes or greenlets or whatever.)
Key search is embarrassingly parallel, which is basically a term of art that means "it's so easy anything works".
In fact, "I'm just starting with Erlang/Haskell/Go and I wanted to play with parallelization so I took the first 100 million integers and spawned a thread to add each individual pair together in a distributed fashion and it's ten thousand times slower than just using a C loop, WTF?" is a very popular post on the relevant language forums. In that situation what happens is because the "payload" of each thread is a single machine-language instruction (give or take loading and saving to memory), all you see is the overhead of starting, stopping, and joining threads. (Or processes or greenlets or whatever.)
Key search is embarrassingly parallel, which is basically a term of art that means "it's so easy anything works".
Erlang uses concurrent processes for stability and soft scaling,
not for speed.
If you want to decipher stuff, program a gpu not cpu.
Highly unlikely to be helpful if good randomness is used for key generation; the security parameters of most encryption schemes means that with the fastest known algorithms, you can't break crypto without exhausting the known energy content of the universe =)
Any implementation for Ruby or Python?
The wiki lists an "in progress" python implementation:
https://github.com/anupsv/The-Noise-Protocol
https://github.com/anupsv/The-Noise-Protocol
simple fast and secure, pick any two?
I'm not sure is particularly necessary to choose. It's true that many protocol design concerns are highly complicated beasts. Do you care about repudiation, or do you want the exact opposite? Do you care about your entire protocol being indistinguishable from random to prevent fingerprinting? What are your performance requirements?
I think this is where the real challenges lie. We've got plenty of good tools for most of this, and we're now seeing protocols like Noise and STROBE that break new ground past TLS and in many cases help fill gaps TLS left open. You don't need to understand all of the design choices in those protocols in order to be able to write useful applications on top of them.
There are plenty of experimental tools left, like SNARKs and multiparty computation and all sorts of cool stuff -- but that's OK, we can take out this class of problems first.
I think this is where the real challenges lie. We've got plenty of good tools for most of this, and we're now seeing protocols like Noise and STROBE that break new ground past TLS and in many cases help fill gaps TLS left open. You don't need to understand all of the design choices in those protocols in order to be able to write useful applications on top of them.
There are plenty of experimental tools left, like SNARKs and multiparty computation and all sorts of cool stuff -- but that's OK, we can take out this class of problems first.
[deleted]
Eephas2o(3)
Reading "I am a cryptographer" got me wary, looking back at your comments, I see that you did this multiple times before and I've tried looking you up but I couldn't find anything that substantiates that claim, I've looked also for publications and couldn't find any so I am curious, what are your credentials?
We detached this subthread from https://news.ycombinator.com/item?id=13405043 and marked it off-topic.
I try to keep my resume to myself unless absolutely necessary because a) recruiters b) arguments to authority are damaging, but Crypto 101[0] is probably the most interesting public one. Other than that, being one of the founders and the resident cryptographer of PyCA and Latacora, also caesium and magicnonce specifically.
[0]: https://www.crypto101.io
[0]: https://www.crypto101.io
I think you completely misread that comment. He was just trying to say he wasn't involved but he has enough domain knowledge that he should be able (and is willing) to answer questions about the protocol. Not, "believe me when I say things because I'm a cryptographer."
- 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.