Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.



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.


> 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.


> 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.


Why don't we hybridise all crypto? We'd get more security if we required RSA+ECDSA+ED25519 at all times, right? Or is the answer that the benefits are small compared to the drawbacks? I am unqualified to provide an answer, but I suspect you are also, and the answer we have from a whole bunch of people who are qualified is that they think the benefits aren't worth it. So why is it fundamentally and obviously true for PQC? This isn't actually an engineering hill I'd die on, if more people I trust made clear arguments for why this is dangerous I'd take it very seriously, but right now we basically have djb against the entire world writing a blogpost that makes ludicrous insinuations and fails to actually engage with any of the counterarguments, and look just no.


FWIW, https://blog.cr.yp.to/20240102-hybrid.html reads to me like a more direct attempt to engage with the counterarguments.

I am curious what the costs are seen to be here. djb seems to make a decent argument that the code complexity and resource usage costs are less of an issue here, because PQ algorithms are already much more expensive/hard to implement then elliptic curve crypto. (So instead of the question being "why don't we triple our costs to implement three algorithms based on pretty much the same ideas", it's "why don't we take a 10% efficiency hit to supplement the new shiny algorithm with an established well-understood one".)

On the other hand, it seems pretty bad if personal or career cost was a factor here. The US government is, for better or worse, a pretty major stakeholder in a lot of companies. Like realistically most of the people qualified to opine on this have a fed in their reporting chain and/or are working at a company that cares about getting federal contracts. For whatever reason the US government is strongly anti-hybrid, so the cost of going against the grain on this might not feel worth it to them.


Which insinuations do you think are ludicrous? Is it not a matter of public record at this point that the NSA and NIST have lied to weaken cryptography standards?


The entirely unsupported insinuation that the customer Cisco is describing is the NSA. What's even supposed to be the motivation there? The NSA want weak crypto so they're going to buy a big pile of Ciscos that they'll never use but which will make people think it's secure? There are others, but on its own that should already be a red flag.


The article links a statement from an NSA official that explicitly says the NSA has been asking vendors for this, which seems like fairly strong support to me.


>So why is it fundamentally and obviously true for PQC? This isn't actually an engineering hill I'd die on, if more people I trust made clear arguments for why this is dangerous I'd take it very seriously, but right now we basically have djb against the entire world writing a blogpost that makes ludicrous insinuations and fails to actually engage with any of the counterarguments, and look just no.

As a response to this only, while djb's recent blog posts have adopted a slightly crackpotish writing style, PQC hybridization is not a fringe idea, and is not deployed because of djb's rants.

Over in Europe, German BSI and French ANSSI both strongly recommend hybrid schemes. As noted in the blog, previous Google and Cloudflare experiments have deployed hybrids. This was at an earlier stage in the process, but the long history of lattices that is sometimes being used as a (reasonable) argument against hybrids applied equally when those experiments were deployed, so here I'm arguing that the choice made at the time is still reasonably today, since the history hasn't changed.

Yes, there is also a more general "lots of PQC fell quite dramatically" sentiment at play that doesn't attempt to separate SIKE and MLKEM. That part I'm happy to see criticized, but I think the broader point stands. Hybrids are a reasonable position, actually. It's fine.


If anyone is curious about DSI's and ANSSI's positions referred to in this comment:

The german position:

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat...

"The quantum-safe mechanisms recommended in this Technical Guideline are generally not yet trusted to the same extent as the established classical mechanisms, since they have not been as well studied with regard to side-channel resistance and implementation security. To ensure the long-term security of a key agreement, this Technical Guideline therefore recommends the use of a hybrid key agreement mechanism that combines a quantum-safe and a classical mechanism."

The french position, also quoting the German position:

https://cyber.gouv.fr/sites/default/files/document/follow_up...

"As outlined in the previous position paper [1], ANSSI still strongly emphasizes the necessity of hybridation1 wherever post-quantum mitigation is needed both in the short and medium term. Indeed, even if the post-quantum algorithms have gained a lot of attention, they are still not mature enough to solely ensure the security"


> Why don't we hybridise all crypto?

So you've constructed a strawman. Another indication of ceding the argument.

> and the answer we have from a whole bunch of people who are qualified

The ultimate job of a manager or a board is to take responsibility for the decisions of the organization. All of your comments in this thread center around abdicating that responsibility to others.

> This isn't actually an engineering hill I'd die on

Could have fooled me.

> we basically have djb against the entire world

Many of your comments indicate to me that clashing personalities may be interfering with making the right engineering decision.


If the argument is "Why adopt a protocol that may rely on a weak algorithm without any additional protection" then I think it's up to you to demonstrate why that argument doesn't apply to any other scenario as well.


Again with the strawmen.

"Why adopt a protocol that may rely on a weak algorithm without any additional protection"

Does not accurately represent the situation at hand. And that seems intentional.

"Why weaken an existing protocol in ways we know may be exploitable?" is a more accurate representation. And I believe the burden of evidence lies on those arguing to do so.


Kyber is not known to be weaker than any other well used algorithm.


Another strawman. No one in this thread said Kyber was known to be weaker. Just that elliptic curve cryptography is well tested, better understood as a consequence of being used in production longer, and that removing it opens up transmissions made without both to attacks on the less widely used algorithm which would not otherwise be successful.

It really seems like you're trying not to hear what's been said.


As a friendly reminder, you're arguing with an apologist for the security-flawed approach that the NSA advocates for and wants.

There are absolutely NSA technical and psychological operations personnel who are on HN not just while at work, but for work, and this site is entirely in-scope for them to use rhetoric to try to advance their agenda, even in bad faith.

I'm not saying mjg59 is an NSA propagandist / covert influencer / astroturf / sockpuppet account, but they sure fail the duck test for sounding and acting like one.


Appreciated. I'll only note that if this is the kind of resistance DJB encountered when raising his objections it goes a long way toward explaining why he might choose to publish his complaints publicly and lends additional credibility to his position.

It has certainly affected my perception of the individuals involved.


Matthew Garrett is not a secret NSA propagandist.

People can reasonably disagree with the djb position. His blog posts are notoriously divisive, and that doesn't make everyone on the other side a secret NSA influencer.

Please assume good faith, or discussions turn into personal attacks and wild accusations.


I didn't claim mjg59 is NSA. I said their arguments function like NSA advocacy. Whether that's by design or coincidence doesn't change the effect. When someone consistently advances positions that serve surveillance state interests using procedural deflection to avoid security substance, noting that pattern isn't a personal attack - it's public, transparent, community-led threat assessment. Pointing out behavior that is functionally indistinguishable from NSA discourse manipulation in a community technical forum - in a conversation about NSA discourse manipulation in community technical forums, no less - isn't a personal attack, it's a social IDS system firing off an alert for a known-bad signature detection.


The effect of claiming that people act like NSA propagandists is indistinguishable from claiming they are an NSA propagandist, except that the wording allows you to weasel out of it.

This turns a thread about cryptography into a thread about attacking someone's particular posting style. This is not going to advance the discussion in any sort of useful direction, the only thing this can do is divide people further while cementing existing positions.

If your IDS thinks well-known free software people are NSA agents because they disagree in a style you don't like, the problem is with the IDS.


If someone doesn't want to be characterized as sounding like an NSA advocate, perhaps they should consider not advocating for NSA objectives.

Anyway, sounds like I'm being dismissed for being "divisive" despite raising substantive security concerns, just like djb. Readers: form your own conclusions about the repetitive patterns here; don't listen to the people telling you not to trust your own eyes.

Note the hallmarks: zero engagement with the substance of the critique (functional equivalence), ad-hom strawman attacks against my character as a response to a misrepresentation of my position, emotional manipulation techniques: demanding focus on tone / civility, maligning moral character of opponent (accusations of divisiveness), still trying to reframe a critique about behavior into an attack against identity that it isn't.


This quacking of theirs just gives them out as a duck many of us suspected them to be.


It is uncouth to accuse a person of being an X without evidence.

It is dishonest to state categorically that a person is not an X unless a person is in the position to know.

A pattern of behavior is a kind of evidence and the observed pattern of behavior does not seem to be in dispute.

There is no evidence presented that the person making a categorical statement is in a position to know about anyone's role or lack of a role in the NSA's clandestine activities.


I fully agree Matthew Garrett is not a secret NSA propagandist. There is a much simpler explanation.

In 2016, Isis Lovecruft was romantically involved with Jacob Appelbaum. Isis lost a coveted PhD student spot studying under Bernstein to… Jacob Appelbaum. Isis broke up with Jacob and accused him of sexual abuse in a spectacularly public manner.

Isis became romantically involved with Henry de Valence, another Bernstein PhD student. Valence became acquainted with Appelbaum. Later, under Isis’ direction, Valence published a wild screed full of bizarre accusations trying to get Appelbaum expelled and Bernstein fired. When this failed, Isis dumped Valence and publicly accused him of sexual abuse.

Isis Lovecruft is now married to Matthew Garrett. Obviously Matthew is going to work to discredit Bernstein, because if he fails, he knows what the next two steps are.


ML-KEM as standardized by NIST is weaker than Kyber.


> If you show up to my manager demanding to know why I made a specific engineering decision, he's not going to tell you

Well if your working in a standards development organisation then your manager probably should.

It looks like (in the US at least) standards development organisations have to have (and follow) very robust transparency processes to not be default-liable for individual decisions.

(Unlike most organisations, such as where where you and your manager from your scenario come from)


This is just a bureaucracy making up fake excuses. qsecretary, the autoresponder, is way less annoying than having to create a new account everywhere on each SaaS platform. At least you know your mail arrived.

Everyone has no issues forcing other people to use 2FA, which preferably requires a smartphone, but a simple reply to qsecretary is something heinous.

The $250 are for spam and everyone apart from bureaucrats who want to smear someone as a group knows that this is 1990s bravado and hyperbole.


If you have nothing to hide, feel free to mail me your unlocked phone.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: