Neat, thanks for the writeup!
I think a single creator-admin for small groups is a nice, simple, and practical design point.
I did want to point out that Matrix does do distributed eventually-consistent authorization, which is their key invention IMHO. (Rooms are distributed among the homeservers, none of which are privileged over the others. You could (and their long-term plan from back in the day) was to run a tiny little single-device homeserver on every device to achieve P2P.)
It's tricky, but a very cool algorithm! Several entities (including myself as a hobby project) are working in combining the Matrix eventually-consistent CRDT with MLS for encryption for a no-compromise distributed E2EE system. It's possible, but very hard, as you might imagine.
This is genuinely cool (and weird that I haven't heard of it). I released the 1.0 version today, but I'm already thinking about improvements for v2. Hopefully you will figure it out and I can implement it for v2 haha
This has been discussed before, and I believe the general consensus is that djb's objections don't make sense. The Key Material blog addresses this in a very good larger ML-KEM mythbusting post: https://keymaterial.net/2025/11/27/ml-kem-mythbusting/#:~:te...
- European group could not be infiltrated by a state-actor with 100billion/y budget and a history of doing so?
- NOBUS today would not be secret in the algorithm but a quantum algorithm/device. Just a month ago HN was getting flooded with "PQC is probably required by 2030".
quantum algorithm would make pure ML-KEM bad to support for the NSA. If the NSA has a quantum computer, they would want to delay proliferation of post-quantum schemes as long as possible, so they could get as much milage out of it as possible before people switch over.
Ironically, this (delaying PQC rollout/standardization) is arguably what DJB has been doing the ~decade, and what his current post is doing.
I was under the impression certain dedicated single-algorithm quantum computers might be much easier to build; allowing you to attack some construct but not yet do full Shor.
PS I'm not saying that's whats happening. Just trying to nail down the scope of what is possible (not plausible).
you're talking about what is known as NISQ quantum computers, namely quantum computers before they can do full error correction. There are no claimed cryptanalytic benefits for NISQ machines. The main claims I've seen are for quantum chemistry simulation, but even those I've heard are not too credible.
Even dedicated single-algorithm quantum computers aren't magic. Given a dedicated single-algorithm quantum computer for attacking ML-KEM, the best current cost estimate we have for it is undoubtedly slower than the classical attack. Attacking ML-KEM quantumly is thought to take exponential (quantum) time. this is (clearly) not the case for ECC.
the IETF TLS working group has limited time/energy. He has been (very successfully) taking up a good deal of this with very annoying procedural techniques (and his most recent move, spreading falsehoods regarding an RFC then asking people to brigade a vote on the RFC). Explicitly, this slows down standards, which delays the PQ transition.
Again explicitly, this is not the main RFC for PQ TLS, which details a hybrid construction. This is an RFC with "recommended to implement = N" marked about how to do PQ TLS 1.3 in environemnts where hybrids are too expensive, for example hardware where it necessitates both a SHA2 and SHA3 impl.
> This is an RFC with "recommended to implement = N" marked about how to do PQ TLS 1.3 in environemnts where hybrids are too expensive
I think the argument boils down to this, yeah.
I am not a cryptographer, nor I’m participating in IETF (yet :), but he does make a good argument on why sticking with a hybrid for the time being makes sense (in between of all the NSA tinfoil hat stuff). And from an outsider point of view, publishing this as an RFC would somewhat legitimize using ML-KEM alone even though it’s marked as Recommended: N. (I would rather prefer waiting until we can publish it as Recommended: Y instead!)
If there are environments where ECDHE-MLKEM is really that much more expensive than ML-KEM alone, could we figure out another hybrid construction instead? E.g. one that only uses SHA3, if that’s the problem.
this is not what I said before. As I mentioned in the post you replied to, there are certain scenarios (e.g. hardware) where pure ML-KEM has significant performance benefits. It instead should not be the default implementation suggestion.
That post says very clearly at the beginning that hybrids are the preferred approach right now.
No one except the NSA actually wants a non-hybrid.
Which raises the question what is the NSA up to.
Especially since the NSA has a mission statement, a track record, and a billion dollar budget to subvert other peoples cryptography. When they aren't beyond transparent why should anyone give them the benefit of the doubt?
Saying that there's no "Nobody but us backdoor" to prove there's *no* backdoor of *any kind* is clearly naive at best, dishonest at worst.
As an example - if there's a weakness that affects 50% of keys (replace with whatever hypothetical number), NSA can make sure it doesn't use those affected keys but still retain the ability to decrypt 50% of everyone else's communications. And using the entropy analysis from this post, that would require 1 bit hidden in the parameters which is clearly within the entropy budget.
A NOBUS backdoor in an asymmetric primitive that looks like "X% of all keys is weak" would not explain "let's move the entire fucking federal governnent to this algorithm including implementations sourced by the private sector that don't do our secret sauxe".
Dual_EC_DRBG is the shape of backdoor that would need to apply here: even if you knew the structure of it, you would need an additional private number to attack it. Recall the Juniper vulnerability where another threat actor simply replaced the EC public key used by Juniper's Dual_EC implementation.
NOBUS without some mathematical assurance that, even should an adversary discover the same break through, they cannot decrypt the same traffic would be too risky when you consider the NSA's self interest and dual mission.
> A NOBUS backdoor in an asymmetric primitive that looks like "X% of all keys is weak"
That’s not a NOBUS backdoor. It’s a different type of backdoor and I’m pointing out that proving there is no NOBUS backdoor doesn’t mean there’s no other backdoor.
It’s a counterexample that I came up with in 5 minutes, not a proof that it’s useful to a state actor.
I recently bought an X4, put crosspoint on it, and have been loving it. I've been reading so much more than before, just because it's always available on the back of my phone.
The article is talking about "Kernel" as in a low level piece of code to compute math, in this case extended attention for running LLMs on a GPU or accelerator, not as in the Linux Kernel.
The two methods that seem feasible are making it hard to copy (putting it in the secure element in your phone, for example, which I don't love) or doing tokens that can only be used a limited number of times per day, like in : https://eprint.iacr.org/2006/454
If it's a rolling cert with rate limits I think that solves the problem, particularly if access to the client cert allows the client to make a financial transaction, e.g. of $100. So you wouldn't share the client cert with randoms because they would just take your $100 and you'd be blocked.
As I posted at top level, they've already backed off, but even the linked version had a carve out for video games:
(B) Does not include:
...
(ii) A bot that is a feature of a video game and is limited to
replies related to the video game that cannot discuss topics
related to mental health, self-harm, or sexually explicit content, or
maintain a dialogue on other topics unrelated to the video game
It's really hard to prevent a general-purpose LLM from doing those. Especially the last one; any topic unrelated to the game is forbidden, not just the ones you slapped a second LLM on top to monitor for.
