
Noise: Box and pipe cryptographic core - mmastrac
https://github.com/trevp/noise/wiki 
======
trevp
FWIW this is on hold until I know for sure what high-security-margin curve to
use. I'd like this to be a "one-ciphersuite-fits-all" protocol, which puts a
lot of pressure on getting that choice right.

In addition to DJB's Curve41417 (not yet implemented), Mike Hamburg's
Goldilocks-448 curve looks pretty good, so I'm waiting for that to shake out.

[http://sourceforge.net/p/ed448goldilocks/wiki/Home/](http://sourceforge.net/p/ed448goldilocks/wiki/Home/)

The "curves" mailing list will (hopefully) be a good place to track that
discussion:

[https://moderncrypto.org](https://moderncrypto.org)
[https://moderncrypto.org/mail-
archive/curves/2014/000139.htm...](https://moderncrypto.org/mail-
archive/curves/2014/000139.html)

~~~
pbsd
Those two being the choices, I'd go for 41417: arithmetic modulo 2^414-17 is
(to me, at least) simpler, and smaller Edwards coefficient. Performance should
be in the same ballpark, if not faster.

I wonder if a higher security margin curve is really required here, though.
(Block) ciphers usually have to worry about multi-target attacks; 128-bit
security starts to feel small in that scenario. But curves don't have that
problem: you need to actually do 2^128 computation even in the multi-target
case, so it seems less necessary to insist on >256-bit curves. What's the
rationale behind the higher security margin curves?

~~~
trevp
Performance should be in the same ballpark, but I'd rather go with whichever
achieves its security level most efficiently. Goldilocks looks good by that
metric [1], so I'm curious how a Curve41417 implementation compares.

The rationale for an "extra-strength" curve is the hope it might resist future
cryptanalytic breakthroughs. The extra bits aren't needed for brute force, but
if some cryptanalysis comes along in 20 years and lops a bunch of "security
bits" off, you might be glad you had extra ones...

That's a hard thing to quantify, but if we can get, say, 96 extra security
bits for only a ~3.5x slowdown over Curve25519, it seems worthwhile.

[1]
[https://docs.google.com/a/trevp.net/spreadsheet/ccc?key=0Aie...](https://docs.google.com/a/trevp.net/spreadsheet/ccc?key=0Aiexaz_YjIpddFJuWlNZaDBvVTRFSjVYZDdjakxoRkE&usp=sharing#gid=0)

------
tptacek
I don't know if Trevor Perrin is actually promoting this yet (he's been
working on it for awhile). I point that out because one of the things to
notice about this is that it was worked on privately and quietly for a long
time in the hopes of getting it _right_.

That's a characteristic of good cryptosystems.

The wiki itself is highly recommendable; I learned a lot just by reading about
how his design works. This is what "modern" (post-2009?) crypto looks like.

~~~
timmclean
On the properties page, what does he mean by deniability?

> The recipient of a Noise box can authenticate the sender, but cannot produce
> digitally-signed evidence binding the sender to anything.

This seems contradictory -- how can a recipient prove that the expected sender
was the one who sent the box, without having binding evidence?

~~~
twic
The way this is done in the OTR protocol and friends is that the information
is signed, and the recipient is given enough information to verify the
signature, but also to forge the signature.

Given that the recipient knows that they did not forge the signature, they can
infer that the signature is legitimate.

Given that a third party, to whom we fear the recipient might reveal the
message, cannot know that the recipient did not forge the signature, they
cannot infer that the signature is legitimate.

It's possible that i have misunderstood the OTR protocol, or Mr Perrin's claim
about Noise boxes. As a result, please do not infer that the above explanation
is definitely correct!

~~~
makomk
This appears to be essentially how Noise works too. The sender creates a
shared MAC key using ECDH in a way that allows the receiver to obtain it and
confirm it came from the genuine sender (assuming the proposed protocol works
as intended). That shared MAC key is then used to authenticate the ciphertext.
Since only the sender and receipient can obtain that key, the receipient can
verify the message is signed so long as they know their private key isn't
compromised, but they can't prove it to anyone else because they have all the
information needed to fake a valid message of their choice.

------
higherpurpose
It's surprisingly hard to find Noise on Google. This is the problem with
naming something with a very common word.

Other than that, Noise looks very interesting. It's from the same guy who came
up with TextSecure's Axolotl ratchet and I think he was the main or one of the
main (along with Moxie) architects of TACK, in case you're wondering who wrote
this:

[https://whispersystems.org/blog/advanced-
ratcheting/](https://whispersystems.org/blog/advanced-ratcheting/)

[http://tack.io/](http://tack.io/)

~~~
tptacek
I think TextSecure _uses_ the Axolotl construction; it doesn't belong to
TextSecure.

An interesting illustration of the power/benefit of branding: lots of people
who don't really "do" crypto know the name of a key exchange ratchet. There's
a lesson here that is applicable outside of crypto.

------
revelation
When DJB has already designed CurveCP et al, why would we use this? Presumably
he got the usage of his own crypto primitives right.

~~~
e1ven
This is discussed at [https://github.com/trevp/noise/wiki/Noise-properties-
and-pro...](https://github.com/trevp/noise/wiki/Noise-properties-and-protocol-
comparisons#pipe-like-protocols)

CurveCP: CurveCP lacks in-connection forward secrecy and resistance to key-
compromise impersonation for the server. Also, a compromised ephemeral client
key can be used permanently for impersonating the client. CurveCP requires the
client to know the server's key prior to connecting, so trust models based on
server certificates or "Trust-on-First-Use" are not directly supported. Like
NaCl, it has a 128-bit security level.

------
ChuckMcM
I _like_ it. All the first pass '... but what if...' questions are answered in
the simple intro. I'll definitely play around with this one a bit.

------
convivialdingo
Any plans to support a UDP transport? I was intrigued with QUIC, but the
protocol complication and overhead is immense and highly integrated into
Chrome.

