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

NSA and IETF: Fairness

blog.cr.yp.to

Post reply on HN
Print view View original

171–180 of 198 posts

Re: NSA and IETF: Fairness

#171

Post by mswphd »

teravor wrote: post #120
mswphd wrote: post #116

Earlier quoted context omitted.

you would make poor decisions then. McEliece recently (in the last month) had a large new attack against it https://eprint.iacr.org/2026/1232 This doesn't hit classic McEliece yet, but is part of a line of work that Randriambololona has been doing, which are at a minimum very concerning for the security of McEliece.

certainly a concern, and a good reason to use multiple cryptosystems together. unfortunately there are probably similar papers for Kyber which are NSA property and will never see the light of day. they do employ a lot of mathematicians. for applications where key exchange need not be particularly fast or compact, I would even throw in 4096 MP-RSA in (tuned to whatever size the exchange can tolerate) as a hedge agains…

as a heads up, there is another attack paper against McEliece today

https://eprint.iacr.org/2026/1339

Note that this is by someone from the BSI. It's worth mentioning the BSI is very familiar with lattice-based schemes (they recommend using FrodoKEM rather than Kyber, but whatever). Despite this familiarity, the attacks they are able to publish aren't regarding lattice-based schemes, and instead a different scheme Bernstein was affiliated with.

NTRU-derivatives and McEliece derivatives are (objectively speaking) not a good track record to have, PQC-wise.

Re: NSA and IETF: Fairness

#172

Post by grayhatter »

some_furry wrote: post #113
grayhatter wrote: post #104

Earlier quoted context omitted.

You're argument is that I shouldn't think of NIST as a patsy for the NSA, is because the NSA can't possibly be recommending a compromised cipher, because if they were, that would mean this US government org is horribly defective and dysfunctional, where one side didn't know what the other was doing? Incentives are basically all I consider when trying to establish true motive. But you're not required to consider motiv…

> You're argument is that I shouldn't think of NIST as a patsy for the NSA, Incorrect. My argument is that they aren't the same entity. The thing you said is a whole different argument. "I like waffles" "So you hate pancakes" is happening. > Incentives are basically all I consider when trying to establish true motive. But you're not required to consider motive when there's a history or pattern. Yes you are. You need…

> Incorrect. My argument is that they aren't the same entity.

Did I claim they were the same?

> The thing you said is a whole different argument. "I like waffles" "So you hate pancakes" is happening.

uh.... you started it? What are we even doing? I'm not above this kinda comment, but I kinda assumed you were? I'd be interested if you have a take I haven't considered; but not if we're just going to try to make straw man of the other.

> Yes you are. [required to consider motive]. Why render yourself willfully ignorant? That's not how you arrive at truth.

I'm not looking for a pure truth. I'm just looking for a heuristic that's just functional enough to keep me, and my data safe. I don't even want to make a perfect is the enemy of good argument. I'm just pointing out, where my line is. I lack the maths knowledge, practical experience, fucks left to give, and spoons remaining for the things I want to spend my time one. Evaluating every bit of information I could possibly gather, and witholding and judgement is a cute idea, but I've got better things to do. NIST has in tandem with the NSA, lied, and shipped a broken crypto system. Let's pretend I don't consider that to be permanently disqualifying, resign, stand up a completely new group from scratch, black tag/non-salvageable. They've burned the default good will everyone starts with, and then peed on it for good measure. Now they're hiding information AGAIN?!

Nah, I could waste my time trying to find the objective truth. Or I could give NIST the finger, and say, make the person with the remaining good will and trust and fucks left to spend on NIST happy. Only then come back to me. Until then, I refuse, and for the same reason I refuse to review LLM PRs; I'm trying to do things, and [they] are trying to DoS my brain.

Ideally, you'd stop helping [the them], or answer the remaining objections line by line, and publicly? Then I'd have someone else with enough good will that I can trust. Because NIST is doing the opposite if they want my confidence.

Re: NSA and IETF: Fairness

#173

Post by grayhatter »

tptacek wrote: post #117
grayhatter wrote: post #87

Earlier quoted context omitted.

Because NIST chose it, after non-public input from the NSA. But if I am honest, NIST recommending it at all is enough to suspect it of being compromised. I say that as an American, and my non-american friends equally don't trust NIST on crypto topics. The real problem I have is best described as I haven't read a single coherent argument responding to and rejecting the real concerns raised by the individual who after…

This argument is entirely non-falsifiable. You could use the same logic no matter what algorithm won the PQC competition. You can even use Vizzini logic to argue against against algorithms the NIST competition didn't pick.

I'm not making a falsifiable argument. I'm stating that given their history, and current behavior I don't trust NIST and I don't think anyone else should either. They are keeping secrets around a new crypto system, the last time they did that it was to hide a known-broken crypto system.

The controversy over the PQC is the topic at hand. If they'd selected a cipher that didn't carry the objections of someone who's reputation I trust more than NIST. Then I'd trust NIST's decision, by proxy.

Re: NSA and IETF: Fairness

#174

Post by tptacek »

grayhatter wrote: post #173
tptacek wrote: post #117

Earlier quoted context omitted.

This argument is entirely non-falsifiable. You could use the same logic no matter what algorithm won the PQC competition. You can even use Vizzini logic to argue against against algorithms the NIST competition didn't pick.

I'm not making a falsifiable argument. I'm stating that given their history, and current behavior I don't trust NIST and I don't think anyone else should either. They are keeping secrets around a new crypto system, the last time they did that it was to hide a known-broken crypto system. The controversy over the PQC is the topic at hand. If they'd selected a cipher that didn't carry the objections of someone who's rep…

Again: it's not their cryptosystem. They didn't design it. They had no hand in its design, or in any of the research that led up to it. They proctored a competition in which everyone involved was unsurprised by the outcome. A pretty big chunk of every academic cryptographer in the world participated, and if you had put the whole thing to a vote, 60% chance you'd have still gotten Kyber and like I don't know 35% chance you'd have gotten SABER.

That's what's so crazymaking about this. People who actually pay attention to cryptography know all this, so much so that Bernstein sounds deranged to many of them. But he's counting on you not knowing any of it. Which is to say: he's preying on your ignorance. It's a bad scene.

Re: NSA and IETF: Fairness

#175

Post by throw0101d »

ekr____ wrote: post #156
throw0101d wrote: post #152

Earlier quoted context omitted.

I have gotten flack for giving ULA+NPTv6 as a possible solution to an IPv6 multi-homing issue because the RFC that describes it was 'only' "Experimental": * https://datatracker.ietf.org/doc/html/rfc6296 When I pointed out that the NAT(44) RFC (1631/3022) was 'only' "Informational" I got radio silence: * https://datatracker.ietf.org/doc/html/rfc1631

I have no opinion on ULA+NPTv6, other than Experimental doesn't mean you shouldn't use it. How else would people experiment. It does mean that the level of vetting by the IETF is potentially lower. WRT IPv4 NAT, I'm not sure how much we can infer from the status. Many people at IETF were (and some still are) very anti-NAT, in part because they felt that IPv6 was the right solution. As a result, the IETF really avoide…

My general point is that the category or track of an RFC may mean different things to different people (assuming they're even aware of them at all).

Re: NSA and IETF: Fairness

#176

Post by dhx »

tptacek wrote: post #121
dhx wrote: post #93

Earlier quoted context omitted.

To point out some positive examples of what RFCs should include: RFC 5288 s3 (AES-GCM): "Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security."[1] RFC 7748 s5 (X25519): "The cswap function SHOULD be implemented in constant time (i.e., independent of the swap argument)…

You are confused about what this RFC is. It's not the enabling RFC for PQC in TLS, or for MLKEM. It's documentation about a specific set of parameters for doing pure, as opposed to hybrid, MLKEM. It defers the guidance you're looking for to other RFCs.

From RFC8446 (TLSv1.3) sE.4: "In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives."[1]

But draft-ietf-tls-mlkem just handballs to FIPS 203 for description of cryptographic primitives, and FIPS 203 doesn't care about side channel resistance. The token reference to NIST SP 800-227 for how to securely implement MLKEM also offers no suggestions on side channel resistance.

The draft MLKEM IKEv2 RFC[2] has the same problem.

Which standard, if not draft-ietf-tls-mlkem, changes the draft-ietf-tls-mlkem specification of the following cryptographic primitive:

Original: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret."

To include side channel resistance, for example:

Improved: "Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret shared_secret. Decaps() MUST be implemented as a constant time function to ensure the time needed to execute Decaps() does not differ for different sk and ct values."

Some further examples of RFCs which do care about specifying side channel resistance:

RFC 9980 (OpenPGP PQC) s9.3: "This specification makes use of the default "hedged" variants of ML-DSA and SLH-DSA, which mix fresh randomness into the respective signature-generation algorithm's internal hashing step. This has the advantage of an enhanced side-channel resistance of the signature operations according to [FIPS-204] and [FIPS-205]."[3]

RFC 9941 (SSH sntrup761x25519-sha512) s4: "As discussed in the security considerations of [RFC8731], the X25519 shared secret K is bignum-encoded in that document, and this raises the potential for a side-channel attack that could leak one bit of the secret due to the different length of the bignum sign pad. This document resolves that problem by using string encoding instead of bignum encoding."[4]

(this RFC 9941 example has the benefit of showing how draft-ietf-tls-mlkem could take problematic cryptographic primitives from FIPS 203 and tighten the specification within an RFC to enforce side channel resistance)

[1] https://www.rfc-editor.org/info/rfc8446/#appendix-E.4

[2] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-ml...

[3] https://www.rfc-editor.org/info/rfc9980/#section-9.3

[4] https://www.rfc-editor.org/info/rfc9941/#section-4

Re: NSA and IETF: Fairness

#177

Post by grayhatter »

tptacek wrote: post #174
grayhatter wrote: post #173

Earlier quoted context omitted.

I'm not making a falsifiable argument. I'm stating that given their history, and current behavior I don't trust NIST and I don't think anyone else should either. They are keeping secrets around a new crypto system, the last time they did that it was to hide a known-broken crypto system. The controversy over the PQC is the topic at hand. If they'd selected a cipher that didn't carry the objections of someone who's rep…

Again: it's not their cryptosystem. They didn't design it. They had no hand in its design, or in any of the research that led up to it. They proctored a competition in which everyone involved was unsurprised by the outcome. A pretty big chunk of every academic cryptographer in the world participated, and if you had put the whole thing to a vote, 60% chance you'd have still gotten Kyber and like I don't know 35% chanc…

I know the backstory. I know there's no real evidence or proof against Kyber's real security, only questions. I've also read the full email threads that I was able to find. Nearly everyone looks like a shithead. I'm sure they're fine people in real life, but there are so many emails that are covered with contempt for the person they're replying to. Trustworthy people don't act like that. > But he's counting on you not knowing any of it. Which is to say: he's preying on your ignorance. It's a bad scene.

I know all of that, I also know I'm years away from the maths to understand the crypto and decide for myself. So, I'm forced to have an opinion because friends and employers will expect me to have one; like them, I'm also forced to operate on trust. Help me with this one? Because my problem is, the only person in the whole scene with ethos is djb. Not a single person in the stack has their name on *anything* that would allow me to trust them given their previous behavior.

So who's the non-deranged person that can put their ego aside, long enough to go point by point down the "deranged man"'s "psychotic rant". Where something everyone who's paying attention can point to and say, djb has stopped taking his crazy pills, here's what reality looks like. Because I went looking for it when I first heard about it, his blog has been linked to from HN many times. But no one has linked to a single other person. I agree with you, the arguments he's making are barely convincing. But one one side, I have a well respected cryptographer (who might want to consider or respond to the accusations he's becoming a bit eccentric) saying hey, y'all are fucking it up. Directly to the people who actively did something ethically inexcusable. Who not only appear to following the exact same pattern as last time, but no one is willing to put their name and time on the line?

What am I supposed to do? Get on board because NIST recommended it already, and there's the RFC for it, so why bother fighting? Just trust the current or next US administration won't do something I object to... like trying to back door crypto... again... I know you'd never actually make that recommendation... well I hope at least. But really; what would you expect me, someone who still trust djb even though his eccentric writing is desperate for an editor, and also, someone who actively believes the people in charge of NIST are ethically questionable. What should I do? where's the evidence that would convince me to switch from believing the guy working to improve foss crypto, to the org with a history of delivering backdoor'd crypto.

Re: NSA and IETF: Fairness

#178

Post by tptacek »

grayhatter wrote: post #177
tptacek wrote: post #174

Earlier quoted context omitted.

Again: it's not their cryptosystem. They didn't design it. They had no hand in its design, or in any of the research that led up to it. They proctored a competition in which everyone involved was unsurprised by the outcome. A pretty big chunk of every academic cryptographer in the world participated, and if you had put the whole thing to a vote, 60% chance you'd have still gotten Kyber and like I don't know 35% chanc…

I know the backstory. I know there's no real evidence or proof against Kyber's real security, only questions. I've also read the full email threads that I was able to find. Nearly everyone looks like a shithead. I'm sure they're fine people in real life, but there are so many emails that are covered with contempt for the person they're replying to. Trustworthy people don't act like that. > But he's counting on you no…

You're making my point for me. Nobody in the whole world is asking for you to take NIST's word for anything.

The problem here is that literally the only information you have to work with is Daniel Bernstein, a notorious standards crank. The names of the cryptographers vouching for Kyber don't mean anything to you. Peter Schwabe? Leo Ducas? Chris Peikert? You're not a cryptographer, who could reasonably expect you to know who those people are?

And Bernstein knows it, and plays it to the hilt.

But I already pointed this out. You keep bringing it back to NIST, but I keep telling you: if you simply let a panel of PQC contestants with credible affiliations vote on it, you'd have gotten the same outcome. So we're really just going around in circles here.

Re: NSA and IETF: Fairness

#179

Post by tptacek »

dhx wrote: post #176
tptacek wrote: post #121

Earlier quoted context omitted.

You are confused about what this RFC is. It's not the enabling RFC for PQC in TLS, or for MLKEM. It's documentation about a specific set of parameters for doing pure, as opposed to hybrid, MLKEM. It defers the guidance you're looking for to other RFCs.

From RFC8446 (TLSv1.3) sE.4: "In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives."[1] But draft-ietf-tls-mlkem just handballs to FIPS 203 for description of cryptographic primitives, and FIPS 203 doesn't care about side channel resi…

Sir, this is a Wendy's. You're giving me a phone book's worth of RFC cites here but not a lot of indication that you spend a lot of time reading RFCs generally. The RFC we're discussing on this thread is an ancillary publication documenting code points for a specific configuration of MLKEM, which is already extensively documented in other RFCs. Ancillary RFCs like these are for obvious reasons brief.

Re: NSA and IETF: Fairness

#180

Post by grayhatter »

tptacek wrote: post #178
grayhatter wrote: post #177

Earlier quoted context omitted.

I know the backstory. I know there's no real evidence or proof against Kyber's real security, only questions. I've also read the full email threads that I was able to find. Nearly everyone looks like a shithead. I'm sure they're fine people in real life, but there are so many emails that are covered with contempt for the person they're replying to. Trustworthy people don't act like that. > But he's counting on you no…

You're making my point for me. Nobody in the whole world is asking for you to take NIST's word for anything. The problem here is that literally the only information you have to work with is Daniel Bernstein, a notorious standards crank. The names of the cryptographers vouching for Kyber don't mean anything to you. Peter Schwabe? Leo Ducas? Chris Peikert? You're not a cryptographer, who could reasonably expect you to…

My problem is with NIST, your problem is with DJB. Neither of us really want to defend either, (I assume, maybe you do want to defend one of them?) We just disagree which one is more likely to make the world worse.

I'm not taken in by the crazyness on either side, and while if pressed, it's obvious which side I would pick. I'm not so much picking a side, so much as complaining again, how we're letting a group with an earned reputation for being untrustworthy keep secrets about crypto. I hate the whole thing, but that's how little trust I have left in other people. The crazy guy is the on the side I hate less... but what to do?

edit:

> You're making my point for me. Nobody in the whole world is asking for you to take NIST's word for anything.

Literally everyone standardizing on Kyber is asking me to trust NIST, et al, and pay the additional overhead for setting up a TLS connection. I guess you could frame it as they're not asking, because I'm not being physically forced to interact with them... but then I try really hard not to engage with bad faith bait, when I'm able to resist.

Post reply on HN