ECDH P-256 + HKDF
Generates a throwaway keypair, agrees a shared secret with the recipient's public key and derives the content key from it. Much smaller keys than RSA for the same strength, and the sender's throwaway public key travels in the header.
What it is made of
- Kind
- Hybrid public-key envelope
- Protects the data with
- AES-256-GCM, under a random one-time key
- Protects that key with
- ECDH on P-256, then HKDF-SHA-256
- Needs a passphrase
- No — a public key encrypts, the private key opens
- Runs in
- Your browser and the server
What it is
Generates a throwaway keypair, agrees a shared secret with the recipient's public key and derives the content key from it. Much smaller keys than RSA for the same strength, and the sender's throwaway public key travels in the header.
Where it runs
Both lanes. By default the lab runs it in your own browser over the Web Crypto API, so nothing leaves your device — there is no upload, no size limit and no queue. The server lane is there when you want it, and it is the only way an agent or a script can reach the same engine.
Why it is hybrid, and why that is not a shortcut
Public-key cryptography does not encrypt your file. RSA can only encrypt a couple of hundred bytes, and ECDH cannot encrypt anything at all — it agrees on a shared secret. So every real system, this one included, generates a random one-time key, protects the data with that, and protects the key with the public key of whoever is meant to read it. "RSA encrypts your file" is the most common wrong belief about all of this, and the lab shows you the wrapped key sitting in the header.
Try it
Open the Keys bench in the lab, generate a keypair, and seal a file to the public half. Then open it with the private half — and try opening it with a different one, which fails exactly as it should. The lab is a Leumas membership away; everything on this page is free.