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

191–200 of 249 posts

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

#191

Post by tptacek »

johncolanduoni wrote: post #188
tptacek wrote: post #170

Earlier quoted context omitted.

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…

If your point is "reference implementations have never been sufficient for real-world implementations", I agree, strongly, but of course that cuts painfully across several of Bernstein's own arguments about the importance of issues in PQ reference implementations.

Part of this, though, is that it's also kind of an incoherent standard to hold reference implementations to. Science proceeds long after the standard is written! The best/safest possible implementation is bound to change.

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

#192

Post by johncolanduoni »

tptacek wrote: post #123
johncolanduoni wrote: post #111

Earlier quoted context omitted.

DJB has specific (technical and non-conspiratorial) bones to pick with the algorithm. He’s as much an expert in cryptographic implementation flaws and misuse resistance as anybody at NIST. Doesn’t mean he’s right all the time, but blowing him off as if he’s just some crackpot isn’t even correctly appealing to authority. I hate that his more tinfoil hat stuff (which is not totally unjustified, mind you) overshadows hi…

There are like 3 cryptographers in all of NIST. NIST was a referee in the process. The bones he's picking are with the entire field of cryptography, not just NIST people.

They may not be involved with this process, but ITL has way more than 3 cryptographers.

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

#193

Post by johncolanduoni »

tptacek wrote: post #191
johncolanduoni wrote: post #188

Earlier quoted context omitted.

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…

If your point is "reference implementations have never been sufficient for real-world implementations", I agree, strongly, but of course that cuts painfully across several of Bernstein's own arguments about the importance of issues in PQ reference implementations. Part of this, though, is that it's also kind of an incoherent standard to hold reference implementations to. Science proceeds long after the standard is wr…

I don't think it's incoherent. On one extreme you have web standards, where it's now commonplace to not finalize standards until they're implemented in multiple major browser engines. Some web-adjacent IETF standards also work like this (WebTransport over HTTP3 is one I've been implementing recently).

I'm not saying cryptography should necessarily work this way, but it's not an unworkable policy to have multiple projects implement a draft before settling on a standard.

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

#194

Post by tptacek »

cryptonector wrote: post #190
zahllos wrote: post #74

Earlier quoted context omitted.

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.

How would NSA have "placed" a backdoor in Kyber? NSA didn't write Kyber.

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

#195

Post by tptacek »

johncolanduoni wrote: post #193
tptacek wrote: post #191

Earlier quoted context omitted.

If your point is "reference implementations have never been sufficient for real-world implementations", I agree, strongly, but of course that cuts painfully across several of Bernstein's own arguments about the importance of issues in PQ reference implementations. Part of this, though, is that it's also kind of an incoherent standard to hold reference implementations to. Science proceeds long after the standard is wr…

I don't think it's incoherent. On one extreme you have web standards, where it's now commonplace to not finalize standards until they're implemented in multiple major browser engines. Some web-adjacent IETF standards also work like this (WebTransport over HTTP3 is one I've been implementing recently). I'm not saying cryptography should necessarily work this way, but it's not an unworkable policy to have multiple proj…

Look at the timeline for performant non-leaking implementations of Weierstrass curves. How long are you going to wait for these things to settle? I feel like there's also a hindsight bias that slips into a lot of this stuff.

Certainly, if you're going to do standards adoption by open competition the way NIST has done with AES, SHA3, and MLKEM, you're not going to be able to factor multiple major implementations into your process.

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

#196

Post by tptacek »

aaomidi wrote: post #27
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…

Except when the government starts then mandating a specific algorithm. And yes. This has happened. There’s a reason there’s only the NIST P Curves in the WebPKI world.

Yes: because it took forever for curves to percolate into the WebPKI (as vs. the TLS handshake itself), and by the time they did (1) we had (esp. for TLS) resolved the "safe curves"-style concerns with the P-curves and (2) we were already looking over the horizon to PQ, and so there has been little impetus to forklift in a competing curve design.

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

#197

Post by tptacek »

zahllos wrote: post #58
vorpalhex wrote: post #45

Earlier quoted context omitted.

The standard will be used, as it was the previous time the IETF allowed the NSA to standardize a known weak algorithm. Sorry that someone calling out a math error makes the NIST team feel stupid. Instead of dogpiling the person for not stroking their ego, maybe they should correct the error. Last I checked, a quantum computer wasn't needed to handle exponents, a whiteboard will do.

ML-KEM and ML-DSA are not "known weak". The justification for hybrid crypto is that they might have classical cryptanalytical results we aren't aware of, although there's a hardness reduction for lattice problems showing they're NP-hard, while we only suspect RSA+DLog are somewhere in NP. That's reasonable as a maximal-safety measure, but comes with additional cost. Obviously the standard will be used. As I said in a…

Worth noting this concern over as-yet-undiscovered cryptanalytic techniques also applies to Bernstein's preferred SNTRUP.

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

#198

Post by johncolanduoni »

tptacek wrote: post #195
johncolanduoni wrote: post #193

Earlier quoted context omitted.

I don't think it's incoherent. On one extreme you have web standards, where it's now commonplace to not finalize standards until they're implemented in multiple major browser engines. Some web-adjacent IETF standards also work like this (WebTransport over HTTP3 is one I've been implementing recently). I'm not saying cryptography should necessarily work this way, but it's not an unworkable policy to have multiple proj…

Look at the timeline for performant non-leaking implementations of Weierstrass curves. How long are you going to wait for these things to settle? I feel like there's also a hindsight bias that slips into a lot of this stuff. Certainly, if you're going to do standards adoption by open competition the way NIST has done with AES, SHA3, and MLKEM, you're not going to be able to factor multiple major implementations into…

This isn’t black and white. There’s a medium between:

* Wait for 10 years of cryptanalysis (specific to the final algorithm) before using anything, which probably will be relatively meager because nobody is using it

* Expect the standardization process itself to produce a blessed artifact, to be set on fire as a false god if it turns out to be imperfect (or more realistically, just cause everybody a bunch of pain for 20 years)

Nothing would stop NIST from adding a post-competition phase where Google, Microsoft, Amazon, whoever the hell is maintaining OpenSSL, and maybe Mozilla implement the algorithm in their respective libraries and kick the tires. Maybe it’s pointless and everything we’d expect to get from cryptographers observing that process for a few months to a year has already been suitably covered, and DJB is just being prissy. I don’t know enough about cryptanalysis to know.

But I do feel very confident that many of the IETF standards I’ve been on the receiving end of could have used a non-reference implementation phase to find practical, you-could-technically-do-it-right-but-you-won’t issues that showed up within the first 6 months of people trying to use the damn thing.

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

#199

Post by tptacek »

johncolanduoni wrote: post #198
tptacek wrote: post #195

Earlier quoted context omitted.

Look at the timeline for performant non-leaking implementations of Weierstrass curves. How long are you going to wait for these things to settle? I feel like there's also a hindsight bias that slips into a lot of this stuff. Certainly, if you're going to do standards adoption by open competition the way NIST has done with AES, SHA3, and MLKEM, you're not going to be able to factor multiple major implementations into…

This isn’t black and white. There’s a medium between: * Wait for 10 years of cryptanalysis (specific to the final algorithm) before using anything, which probably will be relatively meager because nobody is using it * Expect the standardization process itself to produce a blessed artifact, to be set on fire as a false god if it turns out to be imperfect (or more realistically, just cause everybody a bunch of pain for…

I don't know what you mean by "kick the tires".

If by that you mean "perfect the implementation", we already get that! The MLKEM in Go is not the MLKEM in OpenSSL is not the MLKEM in AWS-LC.

If instead you mean "figure out after some period of implementation whether the standard itself is good", I don't know how that's meant to be workable. It's the publication of the standard itself that is the forcing function for high-quality competing implementations. In particular, part of arriving at high-quality implementations is running them in production, which is something you can't do without solving the coordination problem of getting everyone onto the same standard.

Here it's important to note that nothing we've learned since Kyber was chosen has materially weakened the construction itself. We've had in fact 3 years now of sustained (urgent, in fact) implementation and deployment (after almost 30 years of cryptologic work on lattices). What would have been different had Kyber been a speculative or proposed standard, other than it getting far less attention and deployment?

("Prissy" is not the word I personally would choose here.)

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

#200

Post by supernetworks_ »

tptacek wrote: post #178
supernetworks_ wrote: post #171

Earlier quoted context omitted.

Ah now I see what the question was as it seemed like a non sequitur. I misunderstood the comment by foxboron to be concerns about any backdoors not that P256 is backdoored, I hold no such view of that, surely bitcoin should be good evidence. Instead I was stating that weaknesses in cryptography have been historically put there with some NSA involvement at times. For DB: The brain pool curves do have a worse leak, but…

Can I ask you to respond to the "sanity check" argument you made upthread? What is the "sanity checking" you're implying wasn't done on the P-curves?

I wasn’t talking about P curves, I was talking about NSA having acted as a malicious actor in general so I misunderstood their comment
Post reply on HN