Noise Protocol Framework

by cryptoshere • 10 years ago

243 52 10 years ago

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.

lvh12• 10 years ago

Out of interest, how do you verify the similar design choices? For example, how do you check that, say, your AKE is KCI-secure?

alfalfasprout3• 10 years ago

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.

lvh12• 10 years ago

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.

alfalfasprout3• 10 years ago

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.

lvh12• 10 years 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• 10 years ago

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

tptacek4• 10 years 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.

lvh12• 10 years 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.

pvg2• 10 years 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?

tptacek4• 10 years 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.

awinter-py• 10 years ago

simple fast and secure, pick any two?

lvh12• 10 years ago

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.

saganus2• 10 years ago

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?

lvh12• 10 years ago

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.

malingo• 10 years ago

Is Noise the right answer to any of these crypto "questions"? https://news.ycombinator.com/item?id=9593916

saganus2• 10 years ago

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?

gjkood3• 10 years ago

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.

cipher0• 10 years ago

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?

lvh12• 10 years ago

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

gjkood3• 10 years ago

The silver lining in this exchange chain is that I got to download what looks like a great eBook on Cryptography 101 and a link for future reference. Thank you LVH.

x1798DE• 10 years ago

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."

sctb• 10 years ago

We detached this subthread from https://news.ycombinator.com/item?id=13405043 and marked it off-topic.

aseipp• 10 years ago

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. :)

m3lt3• 10 years ago

Would a implementation in Erlang be useful?

lvh12• 10 years ago

Sure! Why not. BEAM VM is a hosted platform now thanks to Elixir, so things that work on it are useful.

m3lt3• 10 years ago

Ok, seems to me like a fun thing to :)

gjkood3• 10 years ago

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.

Ar-Curunir• 10 years ago

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 =)

m3lt3• 10 years ago

Erlang uses concurrent processes for stability and soft scaling, not for speed. If you want to decipher stuff, program a gpu not cpu.

jerf• 10 years ago

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".

lgierth• 10 years ago

If you want to see Noise in action, applied to a real protocol, check out Wireguard: https://www.wireguard.io/protocol/

zx2c43• 10 years ago

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.

lambdadmitry• 10 years ago

Looks awesome! Do you have any plans for GUI apps?

designium• 10 years ago

Any implementation for Ruby or Python?

technion2• 10 years ago

The wiki lists an "in progress" python implementation:

https://github.com/anupsv/The-Noise-Protocol

baby4• 10 years ago

I come late but there is a video explaining the basics of the Noise Protocol Framework here: https://www.youtube.com/watch?v=ceGTgqypwnQ

technion2• 10 years ago

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.

Noise Protocol Framework

Related Stories