The block cipher almost everything uses. GCM is authenticated — it produces a tag, and a modified ciphertext is detected. The others are not: CBC, CTR, CFB and OFB give confidentiality only, and ECB does not even give that properly, because identical plaintext blocks produce identical ciphertext blocks. Never reuse a GCM nonce under one key — two messages with the same key and nonce lose both.

RFC 8439. A stream cipher with a one-time Poly1305 authenticator, and the AEAD TLS 1.3 offers beside AES-GCM — it is faster than AES wherever there is no AES hardware. ChaCha20 on its own is the raw keystream with no authentication, offered so the difference is visible; the nonce there must not repeat either. The counter starts at 1, because block 0 generates the Poly1305 key.

Do not encrypt anything real with these. Single DES has a 56-bit key and was broken in public in 1998; 3DES has a 64-bit block, which makes it vulnerable to Sweet32 after about 32 GB under one key, and NIST disallowed it after 2023. They are here to read what a legacy system wrote, which is a real and ordinary thing to need. Two-key 3DES (128-bit) is the same algorithm with K3 = K1.

The only mechanism here that encrypts a message directly — and only a very short one: a 2048-bit key carries at most 190 bytes under OAEP-SHA-256. That is not a limit to work around by splitting the message; Hybrid is what every real protocol does, and what CMS, S/MIME and JWE all mean by "RSA". PKCS#1 v1.5 is offered for interoperability and is vulnerable to Bleichenbacher padding-oracle attacks in any setting where an attacker can tell a padding failure from another failure.

There is no "ECC encryption" primitive — an elliptic-curve key agrees a secret, it does not encrypt. ECIES is what is always meant: a fresh ephemeral key pair, ECDH against the recipient's public key, HKDF-SHA256 over the agreed secret, and an AEAD under the result. Encrypting the same message twice gives different ciphertext, because the ephemeral key is new each time. X25519 is a key-agreement curve only and cannot sign, which is the mirror image of Ed25519 on the Digital Signature page.

FIPS 203, formerly CRYSTALS-Kyber — the post-quantum key encapsulation mechanism NIST standardised in 2024, and the one to reach for against “harvest now, decrypt later”. A KEM takes no message: it produces a ciphertext and a fresh shared secret together, which is why this pane has no direct mode. A hybrid combines it with a classical key agreement so that a break of either leaves the other holding. Note the key sizes: an ML-KEM-768 public key is 1,184 bytes against P-256’s 33.

The Mode list mixes a published standard, two drafts and one construction of our own, and the difference matters more than the cryptography. ML-KEM alone is FIPS 203 and settled. X-Wing (draft-connolly-cfrg-xwing-kem) and the six Composite pairings (draft-ietf-lamps-pq-composite-kem-08) are Internet-Drafts — but each has a fixed combiner and a published domain-separation label, so two implementations following the draft agree; this page’s X-Wing is checked against all three of that draft’s own test vectors. The last entry, Ad-hoc, is this page’s own construction: it simply concatenates the two shared secrets and runs HKDF over them. It is sound and it is what this pane has always done, but it is not a wire format anybody else implements — a peer would have to have read our source. It is kept so old ciphertexts still open; prefer X-Wing for anything you want another implementation to read.

When Mode names a specific hybrid, that algorithm fixes its own ML-KEM parameter set — ML-KEM-768 + ECDH P-256 is always ML-KEM-768 — so the Parameter Set selector at left applies only to ML-KEM alone and to the ad-hoc hybrid. The status line always names what was actually used.

DSA cannot encrypt. It is a signature algorithm and its private-key operation produces a signature, not a decryption — so there is no "DSA encryption" pane to build, and any tool offering one is mislabelling something else. What a DSA-shaped key's group does is this: ElGamal, the encryption scheme DSA's key structure comes from, and DHIES, ephemeral Diffie-Hellman over the same group. Textbook ElGamal is malleable — multiply c2 by t and the plaintext becomes m·t, and the scheme itself does not object — which is exactly why the hybrid exists. (This page marks the message with a length byte, so an arbitrary mauling is usually caught on the way back; that is an encoding check, not integrity protection.) To sign with DSA, use the Digital Signature page.

ⓘ There is no post-quantum alg here, and that is a fact about the standards rather than a gap in this page. The pane above will encrypt to ML-KEM, X-Wing and six Composite ML-KEM pairings — but none of them can go in a JWE yet, because no JOSE binding for a post-quantum KEM has been specified. The document that will carry one is draft-ietf-jose-pqc-kem; despite the name, revision 06 specifies only the COSE binding — its running header reads “PQ KEM for COSE”, every binding section registers COSE codepoints, its key-derivation section begins “The key derivation for COSE is performed using KMAC”, and the word “JOSE” appears in it three times, twice in its own filename. So there is currently no registered alg value, no defined header parameter for the encapsulated key, and no JOSE-side KDF context to implement. Inventing them would produce a token nothing else could read. Signatures are the other way round: ML-DSA’s JOSE binding is published as RFC 9964, and the Digital Signature page’s JWS pane offers all thirteen post-quantum alg values today.

The one pane whose output is a protocol artifact rather than raw bytes, and the reason it belongs in this debugger: a compact JWE is what an encrypted ID Token, a JAR request object and an OID4VCI encrypted credential response all are. It is the same module (jose_jwe.js) the VC issuance panes and JWT Tools use, so what this pane produces is what the rest of the debugger consumes. Note A192GCM: the RFC defines it and Chrome refuses every AES-192 operation, so the status line will say so rather than failing with an OperationError.

A password is not a key: it is short, it is guessable, and it has to be stretched. PBKDF2 stretches by iteration count alone, so a GPU closes the gap; scrypt is memory-hard, which is what makes custom hardware expensive. The time the status line reports is the point — you pay it once and an attacker pays it per guess. HKDF is in the list to show what happens when the wrong tool is used: it is fast by design, and fast is exactly wrong here. As PBES2 JWE is the JOSE form (RFC 7518 section 4.8) and the same function that password-protects a downloaded key set on this page and the Digital Signature one.