Post-quantum MFA

Two separate threats#

Shor’s algorithm, run on a sufficiently large fault-tolerant quantum computer, solves the discrete-logarithm problem on elliptic curves in polynomial time. That breaks X25519 and ECDH key agreement, and the ECDSA and Ed25519 signature schemes. No such machine exists today, and estimates of when one might differ widely. The two uses of this cryptography fail in different ways, and on different timescales.

• Confidentiality is exposed now. Traffic recorded today can be stored and decrypted once a machine exists, because the key exchange that protected it can then be reversed. This is the harvest now, decrypt later threat. It applies to any connection carrying data whose value outlasts the time to such a machine, and it can only be countered before the traffic is captured.
• Authenticity is exposed later, but by long-lived keys. A forged signature is only possible once the machine exists. The exposure today comes from keys and signatures that will still be relied on then: root keys with no expiry, licenses verified years after issue, and signed approvals kept as a record and checked again later.

Symmetric primitives are affected differently. Grover’s algorithm gives at most a quadratic speed-up against them, which halves effective key strength; SHA-256 and the HMAC behind time-based one-time codes (RFC 6238) are not broken by it.

The standards#

In August 2024 NIST published FIPS 203, the module-lattice key-encapsulation mechanism ML-KEM, and FIPS 204, the module-lattice digital signature algorithm ML-DSA. Ydentifi signs with ML-DSA-65 and prefers ML-KEM-768 in its key exchange, the parameter sets at NIST security category 3.

The cost is size. An ML-DSA-65 public key is 1,952 bytes and a signature 3,309 bytes, against 32 and 64 bytes for Ed25519. An ML-KEM-768 encapsulation key is 1,184 bytes and a ciphertext 1,088 bytes, against a 32-byte X25519 share. Computation is fast, and for an approval sent once per operation the added bytes are immaterial; for a QR code or a constrained link they are not.

Why hybrid#

A hybrid construction combines a classical and a post-quantum primitive so that an attacker must break both. For key exchange, the session key is derived from both shared secrets; for signatures, both signatures are required and both are verified. The combination is at least as strong as the stronger of its two halves.

The reason to keep the classical half is that the lattice schemes are young. Their mathematics has been studied for well over a decade, but their implementations have had little time in production, and side-channel resistance in particular is still maturing. A defect in the post-quantum half then leaves the system with the protection it has today, not with none; a quantum computer leaves it with the post-quantum half.

Transport: hybrid key exchange#

The phone listener accepts only the hybrid groups X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024: a client that offers none of them is refused at the handshake, so every phone connection has post-quantum key exchange. The relying-party, admin and metrics listeners admit the same hybrid groups alongside the classical ones and select a hybrid group whenever the client supports one; a client that does not falls back to a classical group, and that connection has no post-quantum protection. The server refuses to start a listener if the Go runtime’s hybrid groups have been switched off through its debug settings.

The phone-facing listeners accept only TLS 1.3. The relying-party listener also defaults to TLS 1.3, and can be lowered to TLS 1.2 for client runtimes without dependable TLS 1.3 support. A connection that negotiates TLS 1.2 cannot use a hybrid group, so lowering the floor removes the post-quantum key exchange for exactly those connections. See Configuration.

Licenses and the root of trust#

A deployment verifies its license offline, against the Ydentifi root key built into its binaries, and never contacts Ydentifi to do so. The root key and every license are hybrid: an Ed25519 signature paired with an ML-DSA-65 signature, both verified. These are the longest-lived signatures in the system, which is why they carry the post-quantum half. See Get a license.

Approval signatures#

Each approval is signed on the phone with an ECDSA P-256 key generated in its secure hardware — the Secure Enclave on iOS, StrongBox or the TEE on Android. A device that commits to post-quantum signing at enrollment generates an ML-DSA-65 key as well. The authenticator holds it in encrypted storage tied to that one device rather than in the secure element: the Secure Enclave gained ML-DSA only with iOS 26, and the app also runs on earlier versions. From then on the device signs every approval with both keys over the same digest.

The deployment records the device’s algorithm at enrollment. For a hybrid device it requires the hybrid signature and verifies both halves; it does not accept a classical-only signature from that device. What the signature covers is described in Transaction signing.

What remains classical#

• Certificate signatures in the TLS handshake. The certificates that authenticate each side carry classical signatures: the server’s and the relying parties’ are issued by the operator’s own certificate authority, and the phone presents one it generates itself. Forging one requires a quantum computer at the time of the handshake, which is why key exchange is migrated first.
• The hardware-bound key. On a hybrid device the ECDSA half is protected by the secure element and the ML-DSA half by the platform’s encrypted storage. The two halves therefore rest on different protections, and the combination is no stronger against device compromise than the weaker of them.
• Devices enrolled without the post-quantum commitment, and clients that cannot negotiate a hybrid group, use classical cryptography alone.

The security model as a whole is set out in Security model. The quickstart brings up a deployment with the hybrid transport in about five minutes, and the free tier includes all of it; see pricing and the product page.