- I guess that would have been Silverman etc? That's true there was NTRU before reductions were shown. Good call.
- Source for this loss of security? I'm aware of the MATZOV work but you make it sound like there's a continuous and steady improvement in attacks and that is not my impression.
Lots of algorithms were broken, but so what? Things like Rainbow and SIKE are not at all based on the hardness of solving lattice problems.
- Sure. I'm not American either. I agree, maximum scrutiny is warranted.
The thing is these algorithms have been under discussion for quite some time. If you're not deeply into cryptography it might not appear this way, but these are essentially iterations on many earlier designs and ideas and have been built up cumulatively over time. Overall it doesn't seem there are any major concerns that anyone has identified.
But that's not what we're actually talking about. We're talking about whether creating an IETF RFC for people who want to use solely use ML-KEM is acceptable or not - and given the most famous organization proposing to do this is the US Federal Government it seems bizarre in the extreme to accuse them of backdooring what they actually intend to use for themselves. As I said, though, this does not preclude the rest of the industry having and using hybrid KEMs, which given what cloudflare, google etc are doing we likely will.
- Indeed. Dual_EC was a NOBUS backdoor relying on the ECDLP. That's fair.
My point was more that it looked suspicious at the time (why use a trapdoor in a CSPRNG) and at least the possibility of "escrow" was known, as evidenced by the fact that Vanstone (one of the inventors of elliptic curve cryptography) patented said backdoor around 2006.
This suspiciousness simply doesn't apply to ML-KEM, if one ignores one very specific cryptographer.
- SHA-2 was designed by the NSA. Nobody is saying there is a backdoor.
- I will reply directly r.e. the analogy itself here. It is a poor one at best, because it assumes ML-KEM is akin to "internetting without cryptography". It isn't.
If you want a better analogy, we have a seatbelt for cars right now. It turns out when you steal plutonium and hot-rod your DeLorean into a time machine, these seatbelts don't quite cut the mustard. So we need a new kind of seatbelt. We design one that should be as good for the school run as it is for time travel to 1955.
We think we've done it but even after extensive testing we're not quite sure. So the debate is whether to put on two seatbelts (one traditional one we know works for traditional driving, and one that should be good for both) or if we can just use the new one on the school run and for going to 1955.
We are nowhere near DeLoreans that can travel to 1955 either.
- The commentor means Dual_EC, a random number generator. The backdoor was patented under the form of "escrow" here: https://patents.google.com/patent/US8396213B2/en?oq=USOO83.9... - replace "escrow" with "backdoor" everywhere in the text and what was done will fall out.
ML-KEM/ML-DSA were adapted into standards by NIST, but I don't think a single American was involved in the actual initial design.
There might be some weakness the NSA knows about that the rest of us don't, but the fact they're going ahead and recommending these be used for US government systems suggests they're fine with it. Unless they want to risk this vulnerability also being discovered by China/Russia and used to read large portions of USG internet traffic. In their position I would not be confident that if I was aware of a vulnerability it would remain secret, although I am not a US Citizen or even resident, and never have been.
- ML-KEM and ML-DSA are not "known weak". The justification for hybrid crypto is that they might have classical cryptanalytical results we aren't aware of, although there's a hardness reduction for lattice problems showing they're NP-hard, while we only suspect RSA+DLog are somewhere in NP. That's reasonable as a maximal-safety measure, but comes with additional cost.
Obviously the standard will be used. As I said in a sibling comment, the US Government fully intends to do this whether the IETF makes a standard or not.
- "The government" already have. That's what CNSA 2.0 means - this is the commercial crypto NSA recommend for the US Government and what will be in FIPS/CAVP/CMVP. ML-KEM-only for most key exchange.
In this context, it is largely irrelevant whether the IETF chooses or not to have a single-standard draft. There's a code point from IANA to do this in TLS already and it will happen for US Government systems.
I'd also add that personally I consider NIST P-Curves to be absolutely fine crypto. Complete formula exist, so it's possible to have failure-free ops, although point-on-curve needs to be checked. They don't come with the small-order subgroup problem of any Montgomery curve. ECDSA isn't great alone, the hedged variants from RFC 6979 and later drafts should be used.
Since ML-KEM is key exchange, X25519 is very widely used in TLS unless you need to turn it off for FIPS. For the certificate side, the actual WebPKI, I'm going to say RSA wins out (still) (I think).
- In context, this particular issue is that DJB disagrees with the IETF publishing an ML-KEM only standard for key exchange.
Here's the thing. The existence of a standard does not mean we need to use it for most of the internet. There will also be hybrid standards, and most of the rest of us can simply ignore the existence of ML-KEM -only. However, NSA's CNSA 2.0 (commercial cryptography you can sell to the US Federal Government) does not envisage using hybrid schemes. So there's some sense in having a standard for that purpose. Better developed through the IETF than forced on browser vendors directly by the US, I think. There was rough consensus to do this. Should we have a single-cipher kex standard for HQC too? I'd argue yes, and no the NSA don't propose to use it (unless they updated CNSA).
The requirement of the NIST competition is that all standardized algorithms are both classical and PQ-resistant. Some have said in this thread that lattice crypto is relatively new, but it actually has quite some history, going back to Atjai in '97. If you want paranoia, there's always code theory based schemes going back to around '75. We don't know what we don't know, which is why there's HQC (code based) waiting on standardisation and an additional on-ramp for signatures, plus the expensive (size and sometimes statefulness) of hash-based options. So there's some argument that single-cipher is fine, and we have a whole set of alternative options.
This particular overreaction appears to be yet another in a long running series of... disagreements with the entire NIST process, including "claims" around the security level of what we then called Kyber, insults to the NIST team's security level estimation in the form of suggesting they can't do basic arithmetic (given we can't factor anything bigger than 15 on a real quantum computer and we simply don't have hardware anywhere near breaking RSA, estimate is exactly what these are) and so on.
- Ah no I was just being snarky and not at you. We're all missing (hyper)text markup language as the UI markup layer, plus js. We previously had some kind of alternative "load app from internet" but the runtimes were external (and provided lots of fun security holes).
I completely agree it would be better to rethink what we want and have markup/code/etc optimised to the task of rendering applications. I don't think it'll happen unfortunately.
- We could call it Flash. Or Java Applets.
- Yeah. No revenue. Nobody wants to hear about revenue! It's not about how much you make, it is about how much you're worth and who is worth the most? Companies that lose money.
- End to end could still be default for 1-1 chats. Multi device support turns this into a small group chat but it is doable (Wire did it this way afaik; I think Signal does too).
Small groups could likewise be supported.
I take the point that for large groups client fan out of the double ratchet doesn't scale. We now have MLS but we didn't. There's also an argument of how can you really keep a secret in an open group of a few thousand people.
But on a small, "personal" level, e2e could absolutely be done. Not doing so is a choice, one that conveniently ends with almost everyone's chats stored on servers somewhere.
I would go so far as to say I bet telegram is a goldmine for TLAs.
- You can sort of look up a birth certificate but the service isn't designed for that. It is here: https://www.gro.gov.uk/gro/content/
This is where you get certified copies should you ever need that for interfacing with foreign governments that want them (the European country I live in very much wants a copy of my birth certificate).
It's not an identity check by any means but a legitimate birth certificate ought to be findable here.
But yes birth cert + utility bill is a very, very weak binding to identity.
- I guess we'll have to wait for specifics. Unfortunately "it will have inclusion at its core" doesn't really say much.
They are considering enabling its use for more than just work, so what happens when my grandma forgets to charge her phone before her doctors' appointment?
What happens if you want to give teenagers a dumb phone because you as a parent decide a smartphone isn't appropriate, but they need the ID for the NHS too?
- Please don't give them ideas!
- One of my concerns with this is the assumption that every adult has a suitable smartphone. Do the government plan to hand them out?
- Crucial point on this though: it isn't going to be mandatory. Swiss ID cards are not mandatory either although in practice not having one can be inconvenient.
Next year Swiss ID cards will come in two variants: biometric if you want to travel around the EU and existing plastic card if you just want to have it for Switzerland.
So you can even go so far as to opt out of biometrics providing you don't intend to travel internationally.
This is going to happen anyway (non hybrid) at least inside USG because that's what NSA want.