KeyPears now signs and encrypts every message twice — once with classical cryptography, once with post-quantum cryptography — and there is no option to opt out. The full technical writeup went up on the project blog yesterday. This post is the short version, plus the part nobody wants to say out loud.
Two cryptographic primitives, run independently, both required.
For signatures: every message is signed with Ed25519 and ML-DSA-65, and both signatures must verify before the message is accepted. For message encryption: a shared secret is computed using X25519 and ML-KEM-768, the two halves are concatenated and run through HKDF-SHA-256, and the result keys an AES-256-GCM ciphertext. The composition is AND, not OR. An attacker must defeat both halves to compromise any single operation.
This does not mean KeyPears is “quantum-proof.” It does not mean cryptography is solved forever. As the project blog puts it: “It does not mean ‘quantum-proof.’ It does not mean cryptography is solved forever. It means something narrower and more important: KeyPears no longer depends on classical public-key cryptography alone.” That is the entire claim. Hybrid narrows the failure surface; it does not eliminate it.
Two failure modes the world might face. One: someone discovers a structural flaw in lattice cryptography and ML-DSA or ML-KEM falls. In that world, the classical Ed25519 and X25519 halves still protect every KeyPears message. Two: a cryptographically relevant quantum computer arrives and elliptic curves fall. In that world, the post-quantum halves still protect every KeyPears message. The whitepaper states the threat model in one line: “An attacker must break both classical and post-quantum algorithms to compromise any operation.”
This is the part of the rollout I want to call out, because most “we added post-quantum cryptography” stories you have read this year are only about key exchange. Adding ML-KEM to TLS is a real improvement, but it leaves the authentication layer — the part that decides whether a message is from who it claims to be from — running on classical signatures alone. KeyPears uses composite signatures by default: every message carries an Ed25519 signature and an ML-DSA-65 signature, and the recipient’s server checks both before storing the message. The federation layer is hybrid by definition, not as an opt-in.
There is no setting. There is no opt-in. There is no compatibility mode. Every KeyPears message in production uses both Ed25519 and ML-DSA-65, both X25519 and ML-KEM-768. If you don’t trust lattice cryptography, you are still protected by elliptic curves. If a quantum computer breaks elliptic curves tomorrow morning, you are still protected by lattices. The only way to lose is to be wrong about both at once.
That is the sentence the cautious version of this announcement will not write. Most products treat post-quantum as a flag, a beta, an enterprise SKU, or a future migration. KeyPears treats it as the floor. If a server operator wants to host a KeyPears node, they verify composite signatures. If a user wants to send a KeyPears message, they sign with both keys. There is no path through the system that skips either half.
ML-DSA and ML-KEM keys and signatures are much larger than elliptic-curve keys and signatures. A composite signature runs 3,374 bytes per message (64 bytes Ed25519 + 3,309 bytes ML-DSA-65 + a version byte). An ML-DSA-65 signing key alone is 4,032 bytes; the verifying key is 1,952 bytes. ML-KEM-768 encapsulation keys are 1,184 bytes. That means larger messages, more bytes in the database, and more bandwidth during federation. From the project blog: “For KeyPears, that is a good trade.” It is. Bandwidth is cheap. Re-keying every user on Earth after a cryptographic break is not.
The full technical writeup is on the KeyPears blog. The whitepaper covers the formal protocol, including the four-key model and atomic key rotation. If you want the broader context for why KeyPears exists at all, the alpha launch post is the place to start.
Encrypt it twice.
