Earlier quoted context omitted.
He himself (co-)submitted a lattice KEM to the NIST competition.
Yes, and strongly argued against lattice schemes generally . DJB submitted a lattice scheme under the theory that if the advocates of lattice schemes were able to win the argument about the performance properties then there should be a choice of an extremely conservatively designed one. DJB himself has consistently advocated for Classic McEliece in any application which can accept its performance characteristics (whi…
NSA and IETF: Fairness
101–110 of 198 posts
Re: NSA and IETF: Fairness
#102France and Germany propose hybrid schemes as well: 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 lo…
Re: NSA and IETF: Fairness
#103Earlier quoted context omitted.
But that’s not what the IETF is. They don’t police, they encourage collaboration and standardization between implementers.
Heh heh heh. I recall the early-to-mid-90s when the IETF was a powerhouse, churning out foundational standards and documents monthly, and every time I read a foundational RFC for some protocol I wanted to learn, the "Security Considerations" section was intentionally left completely blank and un-considered. I don't know if it was recklessness or expediency or a very calculated tactic (the Internet was invented by DAR…
"The longest key size allowed for export without individual license proceedings was 40 bits, so Netscape developed two versions of its web browser. The "U.S. edition" had the full 128-bit strength. The "International Edition" had its effective key length reduced to 40 bits by revealing 88 bits of the key in the SSL protocol."
Re: NSA and IETF: Fairness
#104Earlier 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…
> But if I am honest, NIST recommending it at all is enough to suspect it of being compromised. NIST isn't the NSA and doesn't have the NSA's goals in mind. They are briefed by NSA on some matters, sure, but they're not the same organization. NSA has a dual mission: Both SIGINT and COMINT. While the SIGINT folks might rub their hands and laugh evilly at the prospect of backdooring the PQ KEM that the Internet wants t…
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. Even if "It's the way we've always done it", wasn't a much, much stronger motive than thought/reason is for any human. It's both logical and desired to treat something as the most dangerous until proven otherwise.
I used to be a nurse. I remember when working in the ED, I was taught that every single woman on childbearing age who comes into the ED with abdominal pain is an extopic pregnancy until proven otherwise. If you ask a woman if it's possible she could be pregnant, regardless of the truth, many will claim it's impossible. If you blindly trust them, and delay treatment, you could needlessly kill your patient, or leave them infertile. Why would someone lie and risk that? Or how dare your medical team make assumptions like that? Well the alternative is worse, the reality should be easy to prove.
NIST has a history of recommending broken ciphers. That's not a mistake a professional would ever make. So thinking about incentives, I'm going to treat it like it was intentional. Here the group with a history for fucking up, isn't being transparent. I would love it if NIST would say enough to make DJB happy or at least stop pretending like they deserve any trust anymore.
Until then, I don't find "they're probably behaving like rational actors" compelling enough to trust them with keeping secrets from somebody who I actually do trust.
Re: NSA and IETF: Fairness
#105Earlier 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…
> But if I am honest, NIST recommending it at all is enough to suspect it of being compromised. NIST isn't the NSA and doesn't have the NSA's goals in mind. They are briefed by NSA on some matters, sure, but they're not the same organization. NSA has a dual mission: Both SIGINT and COMINT. While the SIGINT folks might rub their hands and laugh evilly at the prospect of backdooring the PQ KEM that the Internet wants t…
"Weaknesses in the cryptographic security of the algorithm were known and publicly criticised well before the algorithm became part of a formal standard endorsed by the ANSI, ISO, and formerly by the National Institute of Standards and Technology (NIST). One of the weaknesses publicly identified was the potential of the algorithm to harbour a cryptographic backdoor advantageous to those who know about it—the United States government's National Security Agency (NSA)—and no one else. In 2013, The New York Times reported that documents in their possession but never released to the public "appear to confirm" that the backdoor was real, and had been deliberately inserted by the NSA as part of its Bullrun decryption program."
https://en.wikipedia.org/wiki/Dual_EC_DRBG
"NSA worked closely with IBM to strengthen the algorithm against all except brute-force attacks and to strengthen substitution tables, called S-boxes. Conversely, NSA tried to convince IBM to reduce the length of the key from 64 to 48 bits. Ultimately they compromised on a 56-bit key"
https://en.wikipedia.org/wiki/Data_Encryption_Standard
The NSA published algorithms are not used for the important US secrets. For these system the classified algorithms of NSA Suite A are used.
https://en.wikipedia.org/wiki/NSA_Suite_A_Cryptography
NSA Suite A was probably used for Space Shuttle comunication. NASA scrambled to recover classified communications gear after the Challenger shuttle disaster in 1986.
https://www.globalsecurity.org/org/news/2003/030206-comsec-s...
Re: NSA and IETF: Fairness
#106Re: NSA and IETF: Fairness
#107Earlier quoted context omitted.
> Unfortunately, we can't yet say that about lattice cryptography, despite it being approximately as well-studied as ECC. this is an absurd claim, lattices may be as well studied as elliptic curves, but not the cryptography.
No, it's not an absurd claim. Lattice key establishment goes back into the mid-1990s, and was at one point a serious contender for the alternative-to-RSA/FFDH algorithm that ECC became. Modern LWE lattice KEM is approximately at the same point in its lifecycle (say, compared to original NTRU) as Curve25519 was to ECDH.
Like for any other cryptographic algorithms, where one or more decades were necessary for a good understanding of their properties, we can expect much more relevant publications about lattice key establishment in the next years, than until now.
Re: NSA and IETF: Fairness
#108Earlier quoted context omitted.
Heh heh heh. I recall the early-to-mid-90s when the IETF was a powerhouse, churning out foundational standards and documents monthly, and every time I read a foundational RFC for some protocol I wanted to learn, the "Security Considerations" section was intentionally left completely blank and un-considered. I don't know if it was recklessness or expediency or a very calculated tactic (the Internet was invented by DAR…
In the 90s, you as a private person were not supposed to have access to encyption which could not be broken by NSA. "The longest key size allowed for export without individual license proceedings was 40 bits, so Netscape developed two versions of its web browser. The "U.S. edition" had the full 128-bit strength. The "International Edition" had its effective key length reduced to 40 bits by revealing 88 bits of the ke…
This was still a very bad policy, but private americans were allowed to have strong cryptography.
Re: NSA and IETF: Fairness
#109Earlier quoted context omitted.
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.
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'…
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.
Re: NSA and IETF: Fairness
#110Earlier quoted context omitted.
But that’s not what the IETF is. They don’t police, they encourage collaboration and standardization between implementers.
The standardization process should weed out 'footguns' that are prone to accidentally (or maliciously) lowering the security bar.