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.

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.

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

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