What is new
Four explainers covering RSA, elliptic curve, ML-KEM and ML-DSA. Two tools that generate real keys and run real encryption and signing, entirely in the browser. Sixteen topic archives so the twenty-four guides can be browsed by subject rather than only by task.
Most post-quantum writing, including some of ours, starts one step past the beginning. It assumes you already know what a key exchange is, that RSA and elliptic curve are different things, and that a signature is not encryption. Plenty of people making migration decisions do not, and there is no reason they should.
So we wrote the step before. Four guides, each explaining one algorithm in plain language, and two tools that let you make a real key and watch what it does.
The four explainers
- What is RSA? - why multiplying two primes protects anything, what a 2048-bit key actually measures, and why it is the algorithm a quantum computer breaks first.
- What is elliptic curve cryptography? - the difference between ECDH and ECDSA, which curve to pick, and why ECC falls *before* RSA rather than after it.
- What is ML-KEM? - what encapsulation means, and why the replacement for RSA key exchange never touches your message.
- What is ML-DSA? - what a signature proves, and where signatures fifty times larger actually hurt.
Each one ends at a command line. The browser shows you the shape of a key; your own machine is where you make one that protects something.
Two tools that run in your tab
The key generator makes real RSA, elliptic curve, ML-KEM and ML-DSA key pairs, either at random or derived from a seed phrase you choose. The encrypt and sign playground runs encryption, decryption, signing and verification against a message you type.
Neither has a network request in it. Your private key is never sent to us because it is never sent anywhere. That is also why neither is where a production key should come from, which the tools say plainly before you use them.
The thing the playground exists to show
Encrypt something with ML-KEM and you get back two separate outputs: an encapsulated key of 1,088 bytes and your actual message ciphertext. Do the same with RSA and there is no encapsulated key at all. ML-KEM does not encrypt your message, it agrees a shared secret and a symmetric cipher does the work. That single misunderstanding causes more bad migration plans than any other.
Both ways of generating a key, because the difference is the lesson
The generator offers random and seed-derived keys side by side. A random key is one nothing can reproduce, so losing it means losing it. A seed-derived key comes back every time from the same phrase, which is how a wallet turns twelve words into keys, and which also means whoever knows the phrase holds the key.
RSA cannot do the second one, and the tool says why on the spot rather than hiding the option: generating an RSA key is a search for large primes, not a derivation, so there is no short path from a phrase to a key pair.
The guides are now browsable by topic
Twenty-four guides were grouped only by what you are trying to do: learn, audit, migrate, or certify. That is the right primary axis and it is useless if what you want is everything about keys. Every guide now carries topic tags, and each topic is a real page rather than a filter that exists only while you are looking at it.
- Keys - nine guides, from what RSA is to choosing between ML-DSA and SLH-DSA.
- Migration - twelve guides on sequencing the move.
- TLS and hybrid - what the deployed internet is actually doing.
- Inventory - finding the cryptography you already have, which is where every migration starts.
- Compliance and deadlines - the mandates and their dates.
The full set is at the guides hub, with a rail down the side for both axes.
Why we built it this way
The honest reason is that abstract explanations of key sizes do not land. Telling someone an ML-KEM-768 public key is 1,184 bytes against X25519's 32 is a fact they will forget. Generating both in the same minute and watching the second box dwarf the first is a thing they will remember when a protocol designer tells them the migration is a drop-in swap.
The tools are built on @noble/post-quantum, the pure-JavaScript library we audited twice and published eighteen findings against. Using the library we reviewed, rather than one we have not, seemed like the least we could do.
All of it is free, none of it needs an account, and none of it sends anything to us.
References
- FIPS 203: Module-Lattice-Based KEM (csrc.nist.gov) - the ML-KEM standard.
- FIPS 204: Module-Lattice-Based Digital Signature Standard (csrc.nist.gov) - the ML-DSA standard.
- RFC 8017: PKCS #1 v2.2 (rfc-editor.org) - RSA as actually implemented.
- FIPS 186-5: Digital Signature Standard (csrc.nist.gov) - ECDSA and the NIST curves.