Live data from Hacker News

NSA and IETF: Can an attacker purchase standardization of weakened cryptography?

blog.cr.yp.to

31–40 of 119 posts

Re: NSA and IETF: Can an attacker purchase standardization of weakened cryptography?

#31
post #23

Earlier quoted context omitted.

Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly.

> Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly. This complaint? https://cr.yp.to/2025/20250812-non-hybrid.pdf Engineering concerns start in section 2 and continue through section 4. It seems you haven't read it.

There's a bunch of content that's not actually the complaint, and then there's section 4 which is the actual complaint and is overwhelmingly about procedure.

Re: NSA and IETF: Can an attacker purchase standardization of weakened cryptography?

#32

Earlier quoted context omitted.

And this gets back to the Dual-EC argument, right? Dual-EC was standardized as this weird government thing that maybe you technically need for FIPS, but obviously if you're seriously designing a cryptosystem you wouldn't choose it. And that seems to be GP's position on non-hybrid PQ as well -- just that the reason for not choosing it is "it introduces risk for very little benefit" instead of "it is obviously a bumbli…

> Dual-EC was standardized as this weird government thing that maybe you technically need for FIPS, but obviously if you're seriously designing a cryptosystem you wouldn't choose it. Unless NSA pays you $10 million, as they did to RSA, to make said obviously bumbling attempt the default in their security products. https://en.wikipedia.org/wiki/Dual_EC_DRBG#Timeline_of_Dual_... https://www.reuters.com/article/us-usa-s…

Yeah. Like, the argument here is that the reason government agencies push stuff into standards is because they do in fact want people to use it. "Well government purchasing is just Like That, surely no one will actually use this option in the real world" is an even weaker counter-argument if the option is not obviously backdoored.

Re: NSA and IETF: Can an attacker purchase standardization of weakened cryptography?

#33
post #31

Earlier quoted context omitted.

> Have you read the complaint? It's not about engineering concerns, it's about whether procedures were followed correctly. This complaint? https://cr.yp.to/2025/20250812-non-hybrid.pdf Engineering concerns start in section 2 and continue through section 4. It seems you haven't read it.

There's a bunch of content that's not actually the complaint, and then there's section 4 which is the actual complaint and is overwhelmingly about procedure.

> and then there's section 4 which is the actual complaint and is overwhelmingly about procedure.

Ah, yes, procedural complaints such as "The draft creates security risks." and "There are no principles supporting the adoption decision.", and "The draft increases software complexity."

I don't know what complaint you're reading, but you're working awful hard to ignore the engineering concerns presented in the one I've read and linked to.

Re: NSA and IETF: Can an attacker purchase standardization of weakened cryptography?

#34
post #26

Earlier quoted context omitted.

I'm asking how, specifically, it "weakens security" and is of "questionable technical merits". The IETF isn't a government body.

It's hard to answer your question without repeating the arguments made in the post itself. Are you implying that djb blew the matter out of proportion?

Poor quality analogy: should ed25519 only have been incorporated into protocols in conjunction with another cryptographic primitive? Surely requiring a hybrid with ecdsa would be more secure? Why did djb not argue for everyone using ed25519 to use a hybrid? Was he trying to reduce security?

The reason this is a poor quality analogy is that fundamentally ecdsa and ed25519 are sufficiently similar that people had a high degree of confidence that there was no fundamental weakness in ed25519, and so it's fine - whereas for PQC the newer algorithms are meaningfully mathematically distinct, and the fact that SIKE turned out to be broken is evidence that we may not have enough experience and tooling to be confident that any of them are sufficiently secure in themselves and so a protocol using PQC should use a hybrid algorithm with something we have more confidence in. And the counter to that is that SIKE was meaningfully different in terms of what it is and does and cryptographers apparently have much more confidence in the security of Kyber, and hybrid algorithms are going to be more complicated to implement correctly, have worse performance, and so on.

And the short answer seems to be that a lot of experts, including several I know well and would absolutely attest are not under the control of the NSA, seem to feel that the security benefits of a hybrid approach don't justify the drawbacks. This is a decision where entirely reasonable people could disagree, and there are people other than djb who do disagree with it. But only djb has engaged in a campaign of insinuating that the NSA has been controlling the process with the goal of undermining security.

Re: NSA and IETF: Can an attacker purchase standardization of weakened cryptography?

#35
post #31

Earlier quoted context omitted.

There's a bunch of content that's not actually the complaint, and then there's section 4 which is the actual complaint and is overwhelmingly about procedure.

> and then there's section 4 which is the actual complaint and is overwhelmingly about procedure. Ah, yes, procedural complaints such as "The draft creates security risks." and "There are no principles supporting the adoption decision.", and "The draft increases software complexity." I don't know what complaint you're reading, but you're working awful hard to ignore the engineering concerns presented in the one I've…

As is made clear from the fact that those issues all link to the mailing list, these are not novel issues. They were raised during discussion, taken into account, and the draft authors concluded they were answered adequately. Complaining about them at this point is fundamentally a complaint that the process failed to take these issues into account appropriately, and the issues should be revisited. Given that this was raised to the IESG, who are not the point of contact for engineering issues, the response is focused on that. There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that.

Re: NSA and IETF: Can an attacker purchase standardization of weakened cryptography?

#36
post #35

Earlier quoted context omitted.

> and then there's section 4 which is the actual complaint and is overwhelmingly about procedure. Ah, yes, procedural complaints such as "The draft creates security risks." and "There are no principles supporting the adoption decision.", and "The draft increases software complexity." I don't know what complaint you're reading, but you're working awful hard to ignore the engineering concerns presented in the one I've…

As is made clear from the fact that those issues all link to the mailing list, these are not novel issues. They were raised during discussion, taken into account, and the draft authors concluded they were answered adequately. Complaining about them at this point is fundamentally a complaint that the process failed to take these issues into account appropriately, and the issues should be revisited. Given that this was…

> There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that.

This is the retort of every bureaucracy which fails to do the right thing, and signals to observers that procedure is being used to overrule engineering best practices. FYI.

I'm thankful for the work djb has put in to these complaints, as well as his attempts to work through process, successful or not, as otherwise I wouldn't be aware of these dangerous developments.

Excuses of any kind ring hollow in the presence of historical context around NSA and encryption standardization, and the engineering realities.

Re: NSA and IETF: Can an attacker purchase standardization of weakened cryptography?

#37
post #35

Earlier quoted context omitted.

As is made clear from the fact that those issues all link to the mailing list, these are not novel issues. They were raised during discussion, taken into account, and the draft authors concluded they were answered adequately. Complaining about them at this point is fundamentally a complaint that the process failed to take these issues into account appropriately, and the issues should be revisited. Given that this was…

> There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that. This is the retort of every bureaucracy which fails to do the right thing, and signals to observers that procedure is being used to overrule engineering best practices. FYI. I'm thankful for the work djb has put in to these complaints, as well as his attempts to work through process, successful or not, as otherwise…

Hey, look, you're free to read the mailing list archives and observe that every issue Dan raised was discussed at the time, he just disagreed with the conclusions reached. He made a complaint to the ADs, who observed that he was using an email address with an autoresponder that asserted people may have to pay him $250 for him to read their email, and they (entirely justifiably) decided not to do that. Dan raised the issue to the next level up, who concluded that the ADs had behaved entirely reasonably in this respect and didn't comment on the engineering issues because it's not their job to in this context.

It's not a board's job to handle every engineering complaint themselves, simply because they are rarely the best suited people to handle engineering complaints. When something is raised to them it's a matter of determining whether the people whose job it is to make those decisions did so appropriately, and to facilitate review if necessary. In this case the entire procedural issue is clear - Dan didn't raise a complaint in the appropriate manner, there's still time for him to do so, there's no problem, and all the other complaints he made about the behaviour of the ADs were invalid.

Re: NSA and IETF: Can an attacker purchase standardization of weakened cryptography?

#38
post #37

Earlier quoted context omitted.

> There's a mechanism Dan can use to push for engineering decisions to be reviewed - he didn't do that. This is the retort of every bureaucracy which fails to do the right thing, and signals to observers that procedure is being used to overrule engineering best practices. FYI. I'm thankful for the work djb has put in to these complaints, as well as his attempts to work through process, successful or not, as otherwise…

Hey, look, you're free to read the mailing list archives and observe that every issue Dan raised was discussed at the time, he just disagreed with the conclusions reached. He made a complaint to the ADs, who observed that he was using an email address with an autoresponder that asserted people may have to pay him $250 for him to read their email, and they (entirely justifiably) decided not to do that. Dan raised the…

> you're free to read the mailing list archives and observe that every issue Dan raised was discussed at the time

As was https://en.wikipedia.org/wiki/Dual_EC_DRBG which was ratified over similar objections.

That made it no less of a backdoor.

> it's not their job

As I said about excuses.

Re: NSA and IETF: Can an attacker purchase standardization of weakened cryptography?

#39
post #37

Earlier quoted context omitted.

Hey, look, you're free to read the mailing list archives and observe that every issue Dan raised was discussed at the time, he just disagreed with the conclusions reached. He made a complaint to the ADs, who observed that he was using an email address with an autoresponder that asserted people may have to pay him $250 for him to read their email, and they (entirely justifiably) decided not to do that. Dan raised the…

> you're free to read the mailing list archives and observe that every issue Dan raised was discussed at the time As was https://en.wikipedia.org/wiki/Dual_EC_DRBG which was ratified over similar objections. That made it no less of a backdoor. > it's not their job As I said about excuses.

They're adhering to their charter. If you show up to my manager demanding to know why I made a specific engineering decision, he's not going to tell you - that's not the process, that's not his job, he's going to trust me to make good decisions unless presented with evidence I've misbehaved.

But as has been pointed out elsewhere, the distinction between the Dual EC DRBG objections and here are massive. The former had an obvious technical weakness that provided a clear mechanism for a back door, and no technical justification for this was ever meaningfully presented, and also it wasn't an IETF discussion. The counterpoints to Dan's engineering complaints (such as they are) are easily accessible to everyone, Dan just chose not to mention them.

Re: NSA and IETF: Can an attacker purchase standardization of weakened cryptography?

#40
post #39

Earlier quoted context omitted.

> you're free to read the mailing list archives and observe that every issue Dan raised was discussed at the time As was https://en.wikipedia.org/wiki/Dual_EC_DRBG which was ratified over similar objections. That made it no less of a backdoor. > it's not their job As I said about excuses.

They're adhering to their charter. If you show up to my manager demanding to know why I made a specific engineering decision, he's not going to tell you - that's not the process, that's not his job, he's going to trust me to make good decisions unless presented with evidence I've misbehaved. But as has been pointed out elsewhere, the distinction between the Dual EC DRBG objections and here are massive. The former had…

> unless presented with evidence

The complaint seems well referenced with evidence of poor engineering decisions to me.

> Dual EC DRBG ... had an obvious technical weakness that provided a clear mechanism for a back door

Removing an entire layer of well tested encryption qualifies as an obvious technical weakness to me. And as I've mentioned elsewhere in these comments, opens users up to a https://en.wikipedia.org/wiki/Downgrade_attack should flaws in the new cipher be found. There is a long history of such flaws being discovered, even after deployment. Several examples of which DJB references.

I see no cogent reason for such recklessness, and many reasons to avoid it.

Continued pointing toward "procedure" seems to cede the case.

Post reply on HN