Noise: Box and pipe cryptographic core(github.com)
github.com
Noise: Box and pipe cryptographic core
https://github.com/trevp/noise/wiki
6 comments
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.
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/
http://tack.io/
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/
http://tack.io/
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.
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.
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.
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.
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.
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?
> 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?
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!
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!
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.
Thanks, this makes sense.
Think of DH key agreement, for example (although this is not precise). Once the agreement has been reached you might "verify" the sender by asking him the key (if he knows it, he is the sender) but you cannot create any binding "signed" certification that he is the sender (knowing a secret you already know is not a signature, you might have faked the communication).
When DJB has already designed CurveCP et al, why would we use this? Presumably he got the usage of his own crypto primitives right.
This is discussed at https://github.com/trevp/noise/wiki/Noise-properties-and-pro...
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.
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.
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/
The "curves" mailing list will (hopefully) be a good place to track that discussion:
https://moderncrypto.org https://moderncrypto.org/mail-archive/curves/2014/000139.htm...
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/
The "curves" mailing list will (hopefully) be a good place to track that discussion:
https://moderncrypto.org https://moderncrypto.org/mail-archive/curves/2014/000139.htm...
Thanks for the pointer to the mailing lists. I have submitted them to gmane.org for indexing. =)
Edit:
They are already up!
http://news.gmane.org/gmane.comp.cryptography.moderncrypto.c...
http://news.gmane.org/gmane.comp.cryptography.moderncrypto.g...
http://news.gmane.org/gmane.comp.cryptography.moderncrypto.m...
The last two error out because they have not yet received any mailings since the registration on gmane.
Edit:
They are already up!
http://news.gmane.org/gmane.comp.cryptography.moderncrypto.c...
http://news.gmane.org/gmane.comp.cryptography.moderncrypto.g...
http://news.gmane.org/gmane.comp.cryptography.moderncrypto.m...
The last two error out because they have not yet received any mailings since the registration on gmane.
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?
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?
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...
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...
I know you are waiting for the curve thing to get settled but it's too bad there's not a C implementation in the repo right now. Today I'm working on a project that could clearly benefit from Noise but since it doesn't exist I have to use CurveCP and try to work around the problems you've identified myself.
I completely get where you're coming from on the "one ciphersuite to rule them all" problem but as an early adopter I would happily use curve25519 as a stopgap until you decide what the One True Curve should be. Instead I have to do my own CurveCP implementation now and then maybe rip it out later.
I completely get where you're coming from on the "one ciphersuite to rule them all" problem but as an early adopter I would happily use curve25519 as a stopgap until you decide what the One True Curve should be. Instead I have to do my own CurveCP implementation now and then maybe rip it out later.
Whats the opinion on E-521? I haven't seen much discussion about it, although its listed on the safecurves site.
Probably a good curve too (nice Mersenne prime, so fast reduction). But I'm not sure it fits into processor words as efficiently as Goldilocks (I'm not an expert here, but someone was trying to explain this to me).
But yeah, those might be 3 good candidates for a higher-security curve (Curve41417, Goldilocks, E-521).
But yeah, those might be 3 good candidates for a higher-security curve (Curve41417, Goldilocks, E-521).