Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NSA and IETF, part 3: Dodging the issues at hand

blog.cr.yp.to

Post reply on HN
Print view View original

181–190 of 249 posts

Re: NSA and IETF, part 3: Dodging the issues at hand

#181

Post by cryptonector »

UltraSane wrote: post #56
supernetworks_ wrote: post #39

Earlier quoted context omitted.

It would be wise for people to remember that it’s worth doing basic sanity checks before making claims like no backdoors from the NSA. strong encryption has been restricted historically so we had things like DES and 3DES and Crypto AG. In the modern internet age juniper has a bad time with this one https://www.wired.com/2013/09/nsa-backdoor/ . Usually it’s really hard to distinguish intent, and so it’s possible to de…

The NSA changed the S-boxes in DES and this made people suspicious they had planted a back door but then when differential cryptanalysis was discovered people realized that the NSA changes to S-boxes made them more secure against it.

Yes, NSA made DES stronger. After first making it weaker. IBM had wanted a 128-bit key, then they decided to knock that down to 64-bit (probably for reasons related to cost, this being the 70s), and NSA brought that down to 56-bit because hey! we need parity bits (we didn't).

Re: NSA and IETF, part 3: Dodging the issues at hand

#182

Post by tptacek »

vessenes wrote: post #134
Foxboron wrote: post #32

Earlier quoted context omitted.

> See for example the many problems of NIST P-224/P-256/P-384 ECC curves What are those problems exactly? The whitepaper from djb only makes vague claims about NSA being a malicious actor, but after ~20 years no known backdoors nor intentional weaknesses has been reliably proven?

in the NIST Curve arena, I think DJB's main concern is engineering implementation - from an online slide deck he published: We’re writing a document “Security dangers of the NIST curves” Focus on the prime-field NIST curves DLP news relevant to these curves? No DLP on these curves seems really hard So what’s the problem? Answer: If you implement the NIST curves, chances are you’re doing it wrong Your code produces in…

He does a motte-and-bailey thing with the P-curves. I don't know if it's intentional or not.

Curve25519 was a materially important engineering advance over the state of the art in P-curve implementations when it was introduced. There was a window of time within which Curve25519 foreclosed on Internet-exploitable vulnerabilities (and probably a somewhat longer period of time where it foreclosed on some embedded vulnerabilities). That window of time has pretty much closed now, but it was real at the time.

But he also does a handwavy thing about how the P-curves could have been backdoored. No practicing cryptgraphy engineer I'm aware of takes these arguments seriously, and to buy them you have to take Bernstein's side over people like Neil Koblitz.

The P-curve backdoor argument is unserious, but the P-curve implementation stuff has enough of a solid kernel to it that he can keep both arguments alive.

Re: NSA and IETF, part 3: Dodging the issues at hand

#183

Post by cryptonector »

vessenes wrote: post #134
Foxboron wrote: post #32

Earlier quoted context omitted.

> See for example the many problems of NIST P-224/P-256/P-384 ECC curves What are those problems exactly? The whitepaper from djb only makes vague claims about NSA being a malicious actor, but after ~20 years no known backdoors nor intentional weaknesses has been reliably proven?

in the NIST Curve arena, I think DJB's main concern is engineering implementation - from an online slide deck he published: We’re writing a document “Security dangers of the NIST curves” Focus on the prime-field NIST curves DLP news relevant to these curves? No DLP on these curves seems really hard So what’s the problem? Answer: If you implement the NIST curves, chances are you’re doing it wrong Your code produces in…

Well, DJB also focused on "nothing up my sleeve" design methodology for curves. The implication was that any curves that were not designed in such a way might have something nefarious going on.

Re: NSA and IETF, part 3: Dodging the issues at hand

#184

Post by cryptonector »

tptacek wrote: post #182
vessenes wrote: post #134

Earlier quoted context omitted.

in the NIST Curve arena, I think DJB's main concern is engineering implementation - from an online slide deck he published: We’re writing a document “Security dangers of the NIST curves” Focus on the prime-field NIST curves DLP news relevant to these curves? No DLP on these curves seems really hard So what’s the problem? Answer: If you implement the NIST curves, chances are you’re doing it wrong Your code produces in…

He does a motte-and-bailey thing with the P-curves. I don't know if it's intentional or not. Curve25519 was a materially important engineering advance over the state of the art in P-curve implementations when it was introduced. There was a window of time within which Curve25519 foreclosed on Internet-exploitable vulnerabilities (and probably a somewhat longer period of time where it foreclosed on some embedded vulner…

Quite true, but the Dual_EC backdoor claim is serious. DJB's point that we should design curves with "nothing up my sleeve" is a nice touch.

Re: NSA and IETF, part 3: Dodging the issues at hand

#185

Post by tptacek »

cryptonector wrote: post #184
tptacek wrote: post #182

Earlier quoted context omitted.

He does a motte-and-bailey thing with the P-curves. I don't know if it's intentional or not. Curve25519 was a materially important engineering advance over the state of the art in P-curve implementations when it was introduced. There was a window of time within which Curve25519 foreclosed on Internet-exploitable vulnerabilities (and probably a somewhat longer period of time where it foreclosed on some embedded vulner…

Quite true, but the Dual_EC backdoor claim is serious. DJB's point that we should design curves with "nothing up my sleeve" is a nice touch.

See, this gets you into trouble, because Bernstein has actually a pretty batshit take on nothing-up-my-sleeve constructions (see the B4D455 paper) --- and that argument also hurts his position on Kyber, which does NUMS stuff!

Re: NSA and IETF, part 3: Dodging the issues at hand

#186

Post by zahllos »

vessenes wrote: post #137
zahllos wrote: post #24

In context, this particular issue is that DJB disagrees with the IETF publishing an ML-KEM only standard for key exchange. Here's the thing. The existence of a standard does not mean we need to use it for most of the internet. There will also be hybrid standards, and most of the rest of us can simply ignore the existence of ML-KEM -only. However, NSA's CNSA 2.0 (commercial cryptography you can sell to the US Federal…

My professors at Brown were walking on QR lattice cryptography well before 1997, although they may not have been publishing much - NTRU was in active development throughout the mid 1990s when I was there. Heating up by 1997 though, for sure.

I guess that would have been Silverman etc? That's true there was NTRU before reductions were shown. Good call.

Re: NSA and IETF, part 3: Dodging the issues at hand

#187

Post by f33d5173 »

yardstick wrote: post #172
f33d5173 wrote: post #167

Earlier quoted context omitted.

That's "rough consensus" as opposed to "consensus".

And that’s what the IETF uses but djb doesn’t like.

He doesn't like it at least in part for lacking a concrete definition. Attempting to pin down what it means or ought to mean is therefore useful.

Re: NSA and IETF, part 3: Dodging the issues at hand

#188

Post by johncolanduoni »

tptacek wrote: post #170
johncolanduoni wrote: post #169

Earlier quoted context omitted.

AES is actually a good example of why this doesn’t work in cryptography. Implementing AES without a timing side channel in C is pretty much impossible. Each architecture requires specific and subtle constructions to ensure it executes in constant time. Newer algorithms are designed to not have this problem (DJB was actually the one who popularized this approach).

Reconcile this claim with, for instance, aes_ct64 in Thomas Pornin's BearSSL? I'm familiar with Bernstein's argument about AES, but AES is also the most successful cryptography standard ever created.

Okay, I should've said implementing AES in C without a timing sidechannel performantly enough to power TLS for a browser running on a shitty ARMv7 phone is basically impossible. Also if only Thomas Pornin can correctly implement your cipher without assembly, that's not a selling point.

I'm not contesting AES's success or saying it doesn't deserve it. I'm not even saying we should move off it (especially now that even most mobile processors have AES instructions). But nobody would put something like a S-Box in a cipher created today.

Re: NSA and IETF, part 3: Dodging the issues at hand

#189

Post by cryptonector »

zahllos wrote: post #24

In context, this particular issue is that DJB disagrees with the IETF publishing an ML-KEM only standard for key exchange. Here's the thing. The existence of a standard does not mean we need to use it for most of the internet. There will also be hybrid standards, and most of the rest of us can simply ignore the existence of ML-KEM -only. However, NSA's CNSA 2.0 (commercial cryptography you can sell to the US Federal…

You're not accurately representing DJB's concern.

His concern is that NSA will get vendors to ship code that will prefer ML-KEM, which, not being a hybrid of ECC and PQC, will be highly vulnerable should ML-KEM turn out to be weak, and then there's the concern that it might be backdoored -- that this is a Dual_EC redux.

Re: NSA and IETF, part 3: Dodging the issues at hand

#190

Post by cryptonector »

zahllos wrote: post #74
blintz wrote: post #70

Earlier quoted context omitted.

> Since ML-KEM is supported by the NSA, it should be assumed to have a NSA-known backdoor that they want to be used as much as possible AES and RSA are also supported by the NSA, but that doesn’t mean they were backdoored.

SHA-2 was designed by the NSA. Nobody is saying there is a backdoor.

One does not place backdoors in hash algorithms. It's much more interesting to place backdoors in key agreement protocols.
Post reply on HN