
Noise Protocol Framework - cryptoshere
https://noiseprotocol.org/
======
lvh
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
What about Noise vs QUIC? Which should end up getting adopted?

~~~
lvh
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.

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

------
lgierth
If you want to see Noise in action, applied to a real protocol, check out
Wireguard:
[https://www.wireguard.io/protocol/](https://www.wireguard.io/protocol/)

~~~
zx2c4
I wrote WireGuard. Happy to answer any questions.

[https://www.wireguard.io/papers/wireguard.pdf](https://www.wireguard.io/papers/wireguard.pdf)

That paper has a bit more in depth elaboration, if you're interested.

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

~~~
zx2c4
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!

------
saganus
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?

~~~
lvh
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
Is Noise the right answer to any of these crypto "questions"?
[https://news.ycombinator.com/item?id=9593916](https://news.ycombinator.com/item?id=9593916)

~~~
tptacek
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.

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

~~~
lvh
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.

~~~
alfalfasprout
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.

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

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

------
m3lt
Would a implementation in Erlang be useful?

~~~
gjkood
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.

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

------
designium
Any implementation for Ruby or Python?

~~~
technion
The wiki lists an "in progress" python implementation:

[https://github.com/anupsv/The-Noise-Protocol](https://github.com/anupsv/The-
Noise-Protocol)

------
awinter-py
simple fast and secure, pick any two?

~~~
lvh
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.

------
cipher0
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?

~~~
lvh
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](https://www.crypto101.io)

~~~
gjkood
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.

~~~
lvh
Glad you liked it!

