main.nu

pqc — post-quantum key encapsulation on the command line, and a probe for whether the servers you talk to are ready for it.

pqc keygen [-l 768] -o NAME write NAME.ek and NAME.dk pqc encaps NAME.ek → NAME.ct and the shared secret pqc decaps NAME.dk NAME.ct → the same shared secret pqc sign-keygen [-l 65] -o N write N.pub and N.key (ML-DSA) pqc sign N.key FILE → FILE.sig pqc verify N.pub FILE FILE.sig → valid / INVALID pqc probe HOST[:PORT]… does this server do post-quantum TLS? pqc bench [-l 768] [-n N] operations per second, here pqc kat self-test against NIST's vectors

Two schemes, one tool: ML-KEM (FIPS 203) replaces the key exchange and ML-DSA (FIPS 204) replaces the signature. The KEM levels are 512, 768 and 1024; the signature levels are 44, 65 and 87, and -l picks whichever family the subcommand belongs to.

ML-KEM (FIPS 203) is the KEM NIST standardised in 2024, and the probe subcommand is the part worth having on a laptop: it completes a real TLS 1.3 handshake and reports which key-exchange group the server actually chose. Offering the hybrid group is not the same as getting it — a server that has not deployed ML-KEM falls back to X25519 silently, and from every other angle the handshake looks the same. This tells you which one happened.

Everything here is pure NURL over stdlib/std/mlkem.nu and stdlib/std/tls.nu: no libcrypto, no liboqs.

API

@ main → i