quantakrypto
Loading…
Loading…
Marmot is MLS-based end-to-end encrypted group messaging over Nostr. Its mandatory ciphersuite is classical throughout - and, more consequentially, a post-quantum ciphersuite alone would still leave a classical root of trust in the identity layer.
Updated Aug 9, 2026
Read this first
Marmot mandates one MLS ciphersuite, and it is classical throughout at the 128-bit level. MLS's forward secrecy and post-compromise security do not help against an adversary who records ciphertext today and breaks X25519 later. Separately, and more importantly: Marmot account identities are Nostr secp256k1 keys, and group membership is authorised by a BIP-340 signature - so adopting a post-quantum ciphersuite would leave the MLS layer post-quantum and the door into it classical.
Marmot supersedes the earlier MLS-based Nostr messaging NIP and is the direction of travel for encrypted group chat on the protocol. It requires every implementation to support MLS ciphersuite `0x0001`, which uses X25519 for key agreement, Ed25519 for signatures, and AES-128-GCM with SHA-256 for the symmetric layer.
MLS provides forward secrecy and post-compromise security across epochs. Both are guarantees about key compromise over time. Neither helps against an adversary who archives ciphertext now and breaks the Diffie-Hellman assumption later: group history recorded today is decryptable in full once X25519 falls, however many times the group has rekeyed since.
That matters more for group messaging than for two-party chat. Archives are long-lived, high-volume, and concentrate many participants' data in one place, which is exactly the profile that makes retroactive decryption worth an adversary's storage budget.
Reading the specification surfaced something that sits outside the ciphersuite question entirely, and it is the substance of our proposal.
A Marmot account identity *is* a Nostr x-only secp256k1 public key. The account-identity-proof component then binds that account to an MLS leaf using a BIP-340 Schnorr signature by the account key. That signature is the root of trust for group membership.
So an adversary who recovers an account's secp256k1 private key - which Shor does from the published public key, and every Nostr public key is published - can mint a valid identity proof authorising an MLS signature key they control, and join a group as that member. Adopting even the fully post-quantum MLS ciphersuite would not close that.
Not a reason to delay the ciphersuite work
The two failures have different timing. A post-quantum KEM protects recorded traffic retroactively, so it has to be deployed before the break. Identity forgery is a live-attack problem that can only be closed by migrating the Nostr-layer signature. Both are needed; neither substitutes for the other. What we argued is that the specification should state the limit rather than let a post-quantum ciphersuite imply an end-to-end guarantee it does not provide.
Not the mandatory ciphersuite. A group can only use a suite supported by every current member and every KeyPackage used to add one, so changing the requirement breaks interoperability for no immediate gain - migration in MLS is gated by the slowest member, not by the algorithm.
The change that can land now is capability advertisement, so groups can negotiate upward the moment every member qualifies. Without it, adoption stalls behind a coordination problem that no amount of algorithm choice solves. Alongside that: name the target suites from the IETF working-group draft, recommend the hybrid suite rather than the pure post-quantum one, and record the identity-layer limitation where implementers will see it.
One deliberate omission: the draft's ciphersuite code points are still unassigned by IANA, so our proposal references them by name only. Minting provisional numbers into another project's registry would be exactly the kind of contribution that creates work rather than removing it.
The point
Encrypted group messaging concentrates exactly the kind of long-lived data that harvest-now-decrypt-later targets. Marmot can close the confidentiality half without breaking interoperability - but it should say plainly that the identity layer authorising group membership stays classical until Nostr itself migrates.
Each item links to the upstream artefact where one exists. Drafts are listed without a link because they have not been submitted yet.
Proposed amendment to the MLS ciphersuite surface: capability advertisement now, named hybrid and pure post-quantum targets from draft-ietf-mls-pq-ciphersuites, and a scope note recording that the account-identity proof remains quantum-vulnerable.
The same reasoning we take upstream is what we apply to client systems.