Hacker News Reader

Comment by tptacek | Hacker News Reader

He's a cryptographer. You're describing cryptographers. You get that other cryptographers designed Kyber/MLKEM, and still more implemented it, right? There are cryptographers besides Daniel J. Bernstein.

View on HN

I do think it's fair to make an argument that DJB's expertise in practical cryptography (both in e.g. engineering against side channel attacks as well as in publishing his own libraries) gives him a reality-minded perspective/attitude.

That said, personally speaking, his behavior as a software publisher (packaging & whatnot) is something I'd call… let's go with "subpar" and leave it at that. So while I do believe it's a fair argument, I'm not accepting it, because from my perspective he isn't putting in the necessary work to really understand software publishing.

Bernstein as a "software publisher" cannot really be compared with anyone else, because what can be considered as great flaws in comparison with others are compensated by equally great advantages.

He has published a very large quantity of open-source software, but after publication he never bothered with any kind of maintenance, which is understandable, because he went on doing other work.

On the other hand, unlike almost any other software packages, those published by him almost did not need any maintenance. The only required changes, after decades since they were written, have been caused by external changes, e.g. the continuous evolution and instability of the Linux APIs and the replacement of various IETF RFCs.

I am still using several software packages written by DJB, which have been run continuously 24/7 for more than a quarter of century, on many servers, without ever causing any kind of problems or incidents, unlike a lot of much more notorious software packages, which had various bugs despite permanent maintenance.

The problem here is that for too many people, Bernstein is one of two living cryptographers with name recognition.

Ah I see what you were trying to say. It read to me (with "He's a cryptographer. You're describing cryptographers.") like you were dismissing that knowledge about implementing and shipping cryptographic libraries is a relevant expertise (or that every cryptographer would have that, which they absolutely don't.) But, yeah, he's one among a whole bunch of experts in some of these fields and certainly shouldn't be given special weight just due to his name recognition.

Even the side channel stuff in particular --- Bernstein was certainly a popularizer of it, but that's been mainstream in cryptography research since the mid-2000s (and, obviously, it's Paul Kocher's claim to immortality).

One very big problem I have with Bernstein's recent activism is the way he writes to an audience you can just very clearly tell he thinks little of. He's assuming everybody who pays attention to this stuff has paid basically no attention at all to any cryptography he himself didn't write about. It's a bad argument, but that's not my big issue; my big issue is that he's making fools of his supporters. Not OK.

"two timing leaks, KyberSlash1 and KyberSlash2, in every official reference Kyber implementation from 2017 through late 2023"

Cryptographers can be good, bad, be more or less knowledgeable about applied cryptography, and possibly have agendas.

Huh, seen through that light, it's much clearer why we should all have ECC in our cryptosystems, because nothing has ever gone wrong with an ECC implementation.

We do all have ECC in our cryptosystems right now, and given how long it's been there, we can rely on its security much more than something new.

So clearly when I go look back at the archives of Bernstein discussing 25519, I'm going to see him advocating for FFDH/25519 cascades, right?

(If my subtext wasn't clear, by the way: the implementation history of ECC is godawful.)

Was FFDH considered safe?

> the implementation history of ECC is godawful

You do know that new cryptographic code can be godawful, then?

This reads to me as an argument of "If you thought ECDSA was bad, wait until you see MLKEM?"

ECDSA history is repeating itself again when you consider how poorly the proposed MLKEM RFC deals with side channel resistance:

From draft-ietf-tls-mlkem-8:[1]

"Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers."

From NIST SP 800-227:[2]

"Cryptographic modules for KEMs should be designed with appropriate countermeasures against side-channel attacks. This includes protecting against timing attacks with constant-time implementations and protecting memory from leakage. Universal guidelines are unlikely to be helpful as exposure to side-channel attacks varies significantly with the desired application, and countermeasures are often costly."

MLKEM is more complex and has more chances of stuff-ups in implementation than ECDSA did. A single sentence of encouragement is all that is on offer from this MLKEM RFC. It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]

As a point of reference for how hard it is to implement side channel resistant MLKEM see [4] (formal verification) and [5] (errors in formal verification). The MLKEM RFC doesn't offer a "Security Considerations" section to explain how difficult it is to implement side channel resistant MLKEM (perhaps it's easy :S), and if it were hard to implement, to recommend use of EdDSA+MLKEM for cryptography implemented on devices an attacker may be able to physically access, or when used on public networks as a workaround given that side channel resistant EdDSA would be easier to implement.

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1

[4] https://github.com/pq-code-package/mlkem-native/tree/main/pr...

[5] https://eprint.iacr.org/2026/192

edit: added reference 5

> A single sentence of encouragement is all that is on offer from this MLKEM RFC.

The draft only specifies the MLKEM binding into TLS; it'd be out of scope for it to go into detail on implementation considerations for MLKEM. Those would belong in or adjacent to FIPS 203 (the actual MLKEM specification).

> It doesn't even have the lightweight "Security Considerations" section which RFC8032 for EdDSA provided.[3]

It's actually RFC8032 that this criticism would apply to, since it is actually specifying EdDSA, not just referencing it externally.

The draft considers FIPS 203 to be normative. Therefore FIPS 203 forms part of this draft. You can't implement this draft without first implementing FIPS 203.

FIPS 203 doesn't care about side channel resistance, per my other comment at [1]. And this draft doesn't do anything to tighten the constraints on how FIPS 203 should be implemented to provide side channel resistance.

[1] https://news.ycombinator.com/item?id=48811887

Not all cryptographers (and cryptography standards) care about real world implementation, or have the same use cases in mind for their cryptography algorithms and protocols. Almost every cryptography standard in common use treats side channel resistance as an optional after-thought for implementers. This might be fine for some users, for example, the US government, because they generally don't implement cryptography on systems an attacker would have physical access to, and don't use cryptography protocols on public networks. For these users, having maximum performance at the expense of side channel resistance might be the best trade-off to make.

For most users however, side channel resistance is a very important property that shouldn't be considered an optional after-thought. If standards bodies made it mandatory to consider side channel resistance when standardising cryptography schemes, the choice of what scheme(s) to standardise could look quite different, and thus general use of cryptography would have improved security by default. If some types of users don't care about side channel resistance, then great, make use of non-side-channel-resistant cryptography optional for them to use. Don't standardise it the other way around.

For example:

FIPS 186-5 sB.1 states: "Other (constant time) algorithms that produce an equivalent result may be used."[1]

NIST SP 800-186 sE.4 states: "If one is concerned about side-channel leakage, one should compute the inverse using a constant-time algorithm."[2]

RFC 8032 s8.1 states: "Note that the example implementations in this document do not attempt to be side-channel silent."[3]

A better standard may, for example, _require_ [4] be implemented in order for an implementation to claim conformance with the standard. Not as an optional after-thought. If there are users wanting to trade off side channel resistance for performance gains, then write a new standard to that effect and remove the requirement to implement [4].

A better standardisation process may, for example, only accept candidate algorithms _if_ they are side channel resistant. This opens up the standard to as many use cases as possible. No cutting corners to pretend performance is better for one implementation because it trades off side channel resistance for performance, and no pretending side channel sensitive use cases don't exist.

[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf

[2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

[3] https://www.rfc-editor.org/info/rfc8032/#section-8.1

[4] https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplic...

I, for one, wouldn't care if Kanye West or his aunt or her neigbours dog came up with a good encryption algo. If it's good, it's good no matter who wrote it. Appeals to authority or the lack thereof draws attention away from the technical debate.

Unfortunately, that's not how modern crypto works. Many mathematical problems on which algorithm rests their security are not proven to be unsolvable, but instead they're believed to be hard to solve. So here are the questions, who believes what is hard, and hard for whom.

Somehow I wouldn't trust my data on mathematical problems, for which the recommendation is that they would challenge Kayne West.

Reply on news.ycombinator.com