Signatures vs KEM: when to use each in post-quantum crypto
A common source of confusion in post-quantum migration is which primitive to reach for. Signatures (ML-DSA/Dilithium) and key encapsulation (ML-KEM/Kyber) are not interchangeable — they solve different problems. Getting this right is the first step in any PQC design, because using the wrong tool leaves a gap in exactly the property you thought you protected.
Signatures answer "who and unchanged?"
A digital signature proves authenticity and integrity: this came from the holder of a specific key and has not been altered. Use ML-DSA (Dilithium, FIPS 204) whenever you need non-repudiation or tamper-evidence — signing documents, code, firmware, audit logs, credentials and transactions. The verifier needs no secret; anyone with the public key can check it. Signatures do not hide the content; they vouch for it.
KEM answers "how do we share a secret?"
A key encapsulation mechanism establishes a shared secret over an insecure channel so two parties can then encrypt traffic between them. Use ML-KEM (Kyber, FIPS 203) wherever you would use Diffie-Hellman or RSA key transport — TLS handshakes, VPN tunnels, encrypted messaging setup. The output is a secret both parties hold, which keys a symmetric cipher. KEM protects confidentiality of a session, not the authenticity of a document.
Most systems need both
Real protocols combine them: a KEM establishes the confidential channel and a signature authenticates the parties and messages. TLS, for instance, uses key exchange for secrecy and signatures for authentication — and a post-quantum TLS uses ML-KEM plus ML-DSA together. Both are resistant to known classical and quantum attacks per NIST, not unbreakable. Map each of your security requirements to the right primitive before choosing parameters.
Try it yourself — live, free, verifiable in 30 seconds:
Explore the PQC API →