tptacek

36 ms·

901.
by tptacek 4mo ago
When you make an argument that is actually somehow rooted in cryptographic research, I'll have something to reply to. This is all just Schneier-Facts(tm) logic.
902.
by tptacek 4mo ago
Unfalsifiable just-so argument. The point is that no matter what NIST selected, you could make this argument. Heads, you win, tails, they lose. There's no actual cryptography involved here.
903.
by tptacek 4mo ago
I don't think you understand the argument you're making here. NSA had no hand in MLKEM itself or even in the line of research that led to MLKEM. Whatever advantage you're claiming they have with respect to MLKEM, I could just
904.
by tptacek 4mo ago
You're just restating the same claim with more words. It obviously proves too much. You can stick any algorithm, from MLKEM to SNTRUP to CRC32, in the same comments and get the same result.
905.
by tptacek 4mo ago
What does this even mean? By the exact same logic you could impeach literally any algorithm.
906.
by tptacek 4mo ago
It's 100 books. Does your house have bookshelves? You have more books than this. It's like a display at a bookstore.
907.
by tptacek 4mo ago
It is if literally the only thing you've ever read about the technical details of LWE cryptography is Daniel Bernstein.
908.
by tptacek 4mo ago
No. In the 1990s, you weren't allowed to export cryptography the NSA couldn't break. Strong cryptography was widely available in the 1990s. (I had the pleasure of shipping a commercial product, back in the days when those things
909.
by tptacek 4mo ago
None of this makes any sense once you understand that NSA had no hand in designing MLKEM, or in shaping the LWE research that led to it. NSA designed Dual-EC. MLKEM won an open competition; its entrants are among the most reputable cryptogr
910.
by tptacek 4mo ago
The general C.W. I've heard is that if something happened that made MLKEM look theoretically shaky (pretty unlikely, but whatever), you fall back to something like FrodoKEM, which is plain LWE with no affordance for NTT or anything lik
911.
by tptacek 4mo ago
You are confused about what this RFC is. It's not the enabling RFC for PQC in TLS, or for MLKEM. It's documentation about a specific set of parameters for doing pure, as opposed to hybrid, MLKEM. It defers the guidance you're
912.
by tptacek 4mo ago
This argument is entirely non-falsifiable. You could use the same logic no matter what algorithm won the PQC competition. You can even use Vizzini logic to argue against against algorithms the NIST competition didn't pick.
913.
by tptacek 4mo ago
The IETF already has a standard hybrid scheme and it's what everybody already uses. That's not what this is about.
914.
by tptacek 4mo ago
His isn't the most conservative lattice construction! This is a hell of a just-so story.
915.
by tptacek 4mo ago
He himself (co-)submitted a lattice KEM to the NIST competition.
916.
by tptacek 4mo ago
The NSA had nothing to do with designing Kyber.
917.
by tptacek 4mo ago
It's "cipher". But we're not talking about ciphers; we're talking about key establishment algorithms.
918.
by tptacek 4mo ago
WireGuard in particular is both an implementation and a design, and the design effectively belongs to Jason Donenfeld. The problem with cryptographic standards bodies is that committee-based design has a long track record of weakening proto
919.
by tptacek 4mo ago
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
920.
by tptacek 4mo ago
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 godaw
921.
by tptacek 4mo ago
For the record, he's always been extremely nice to me, online and in person, and generous with his time. I would maintain TLS the same way WireGuard and OpenSSH are maintained. Both have superior track records. I'm generally an op
922.
by tptacek 4mo ago
The problem here is that for too many people, Bernstein is one of two living cryptographers with name recognition.
923.
by tptacek 4mo ago
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.
924.
by tptacek 4mo ago
You would trust McEliece more than Kyber because...
925.
by tptacek 4mo ago
It already exists. In fact, there are environments where it has to exist. So the argument he's making is that the IETF should pretend it doesn't exist.
926.
by tptacek 4mo ago
This is completely backwards. The more cryptography-literate you are, the more likely it is you think hybrids are silly. Plenty of cryptographers think this is all bullshit, and that ECC+MLKEM makes about as much sense as an AES+Serpent cas
927.
by tptacek 4mo ago
He famously doesn't support the IETF. In the long-long-long ago, back when I had a "home page" with my username and a tilde in it, I used to have a quote from him on it about the IETF and "ego standards". He's
928.
by tptacek 4mo ago
By dint of not including a list of non-cryptographer cosigners, this one is prima facie somewhat less cringe.
929.
by tptacek 4mo ago
These are arguments, but I don't really understand what they're arguments for. At issue here is whether or not the IETF should document usage of pure-MLKEM TLS. There are environments where people are going to use pure-MLKEM TLS
930.
by tptacek 4mo ago
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.

More ›