ML-KEM-768
Also known as: Kyber-768, CRYSTALS-Kyber, Module-Lattice KEM, FIPS 203
ML-KEM-768 is the NIST-standardized lattice key-encapsulation mechanism defined in FIPS 203, formerly the CRYSTALS-Kyber proposal. It lets two parties agree on a shared secret that resists both classical computers and quantum computers running Shor's algorithm. The 768 parameter set targets NIST security level 3, roughly AES-192, and its security rests on the hardness of the Module Learning With Errors problem.
ML-KEM stands for Module-Lattice-Based Key-Encapsulation Mechanism. A KEM is not used to encrypt your messages directly; instead it does one job extremely well: produce a fresh random shared secret and a ciphertext that only the holder of the right private key can open. The sender runs encapsulation against the recipient's public key, which spits out a 32-byte shared secret plus a 1088-byte ciphertext. The recipient runs decapsulation with their private key and recovers the same 32 bytes. That shared secret then seeds a normal symmetric cipher like AES-256-GCM.
What makes it quantum-resistant is the underlying math. Where X3DH and other classical schemes rely on elliptic-curve discrete logarithms (which Shor's algorithm solves in polynomial time), ML-KEM rests on Module Learning With Errors (MLWE) over a polynomial ring. No efficient quantum algorithm is known for that lattice problem.
The 768 is the middle parameter set, with module rank k=3, ring dimension n=256, and modulus q=3329. It maps to NIST security level 3 (comparable to AES-192) and was chosen by many protocols as the sweet spot between key size and margin. ML-KEM was published as FIPS 203 on August 13, 2024, the final form of the algorithm that won the seven-year NIST competition as CRYSTALS-Kyber.
ML-KEM-768 is what most serious deployments standardize on: it is what Apple's iMessage PQ3, Signal's PQXDH, and TLS hybrid drafts settled around.
How it works
Three operations define any KEM. KeyGen produces a 1184-byte public encapsulation key and a 2400-byte private decapsulation key. Encapsulate(pk) samples a random 256-bit seed, derives shared secret and randomness deterministically, and outputs a 1088-byte ciphertext plus a 32-byte shared secret. Decapsulate(sk, ct) decrypts the seed, re-encapsulates internally, and uses implicit rejection: if the recomputed ciphertext does not match, it returns a pseudorandom secret derived from a stored z value rather than an error, defeating chosen-ciphertext oracle attacks. The Module-LWE hardness assumption underlies all three.
How RVNT uses ML-KEM-768
RVNT never uses ML-KEM-768 alone. It runs the KEM alongside classical X25519 in a hybrid handshake: the ML-KEM shared secret is concatenated with the four X25519 Diffie-Hellman outputs and fed through HKDF-SHA256 to derive the session key. An attacker must break both the lattice and the elliptic curve. See post-quantum cryptography and the hybrid key exchange docs.
Frequently asked questions
Is ML-KEM-768 the same as Kyber?
Effectively yes. ML-KEM-768 is the NIST-standardized version of the CRYSTALS-Kyber 768 parameter set. NIST renamed it ML-KEM when it became FIPS 203 in August 2024, and made small tweaks to domain separation and the key-generation API, but the core algorithm is Kyber.
Why 768 and not ML-KEM-1024?
ML-KEM-768 hits NIST security level 3 (about AES-192), which already exceeds the strength of the AES-256 symmetric layer it seeds against a quantum adversary using Grover's algorithm. The 1024 variant gives level 5 with larger keys and ciphertexts; 768 is the widely adopted balance of margin and size, matching Signal and Apple's choices.
Does ML-KEM-768 encrypt my messages?
No. A KEM only establishes a shared secret; it does not encrypt content. That secret is mixed into the session key, and a symmetric cipher (AES-256-GCM in RVNT) actually encrypts the messages.
Every definition here describes something RVNT actually ships — a post-quantum, end-to-end-encrypted, peer-to-peer messenger with no phone number and no servers.