OpenSSL Studio

Interactive OpenSSL v3.6.3 environment running entirely in your browser via WebAssembly. Educational use only — not a FIPS-validated module; the pending FIPS 140-3 validation submission covers the OpenSSL 3.5.4 provider (2025), not the 3.6.x line.

What this means for you

Executive / Business Leader: This is a hands-on engineering tool — a real OpenSSL 3.6.3 running in your browser, not a FIPS-validated module; the banner at the top links you to the Compliance landscape and Migration framework instead.
GRC / Risk & Compliance: The header states plainly that this build is educational and not FIPS-validated; the Explore tab's "Query this build" lists which providers are self-reported versus actually verified, and the banner links to the Compliance landscape.
Developer / Engineer: The "Quick jump" strip drops you straight into genpkey, req, x509, dgst, kem or enc on the Workbench tab — the same binary and flags you would put in a script; "Recent Commands" keeps what you ran.
Security Architect: The Learn tab walks from a first keypair through certificates, key establishment without classical exchange, and packaging keys for the real world; the Workbench tab then runs each step against real files.
Researcher / Academic: The "Related specs" strip links ML-KEM, ML-DSA, TLS 1.3, PKCS#12 and X.509 to their source documents; on the Explore tab, "Query this build" lists the algorithms and providers this exact binary reports.
Certification & Validation Engineer: The header states that this build is educational and not FIPS-validated; on the Explore tab, "Query this build" lists which providers are self-reported and which are actually verified.
IT Ops / DevOps: The "Rotation & inspection" strip is a rotation rehearsal — genpkey to mint the new key, req for the CSR, x509 to inspect issuer, expiry and algorithm, pkcs12 to bundle key and chain; nothing touches your estate.
Curious Explorer: A banner names the roles this page is built for; the Learn tab starts with "Your first keypair — classical, then post-quantum", and the Workbench terminal offers one-click starters such as "Check OpenSSL version".

Best experienced on desktop — scroll down for terminal and file manager.

Core

Your first keypair — classical, then post-quantum

genpkey generates both eras of key with the same command shape — only the -algorithm value changes. Watch what changes (and what stays the same) between an RSA-2048 key and an ML-DSA-65 key.

ML-DSA (FIPS 204) and ML-KEM (FIPS 203) have been native in OpenSSL's default provider since 3.5 (this Studio runs 3.6.3) — no external provider needed. The PQC variant name (e.g. ml-dsa-65) IS the -algorithm value; it is not a -pkeyopt. That trips up first-time users coming from RSA, where key size is a separate -pkeyopt.

Steps

genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out learn-l1-rsa.key
1. Generate a classical RSA-2048 private key
genpkey -algorithm ML-DSA-65 -out learn-l1-mldsa.key
2. Generate a post-quantum ML-DSA-65 private key

Glossary

-aes-128-cbcEncrypt / decrypt with AES-128 in CBC mode
-aes-256-cbcEncrypt / decrypt with AES-256 in CBC mode
-algorithmKey algorithm (e.g. rsa, ec, ml-kem-768, ml-dsa-65)
-base64Base64-encode the output
-binaryTreat the input as raw binary data
-CACA certificate used to sign the certificate
-cacertsOutput only CA certificates
-CAcreateserialAuto-create the CA serial number file if missing
-CAkeyPrivate key of the CA used to sign the certificate
-canameOverride the friendly name for the CA certificate
-certfileAdditional certificates file to include
-certinInput is a certificate (not a raw public key)
-clcertsOutput only client certificates
-dDecrypt mode
-daysCertificate validity period in days
-decryptDecrypt the input using the private key
-digestMessage digest algorithm (e.g. sha256, sha3-256)
-eEncrypt mode (default)
-encryptEncrypt the input for the recipient certificate
-exportExport a PKCS#12 file
-hexEncode output in hexadecimal
-inRead input from this file
-informInput format: PEM, DER, or SMIME
-inkeyInput key for the PKCS#12 bundle or SMIME operation
-iterPBKDF2 iteration count for key derivation
-ivInitialization vector as hex string
-kPassphrase for key derivation
-keyPrivate key file
-keyoutWrite the generated private key to this file
-legacyUse legacy PKCS#12 algorithms (RC2/3DES)
-newGenerate a new CSR (Certificate Signing Request)
-newkeyGenerate a new key pair of the specified type
-nocertsOmit certificates from output
-nodesDo not encrypt the private key (no DES)
-nokeysOmit private keys from output
-nooutSuppress encoded output; print only text form
-nosaltSkip salt in key derivation (not recommended)
-numNumber of random bytes to generate
-outWrite output to this file
-outformOutput format: PEM, DER, or SMIME
-pPrint the salt, key, and IV used
-passinInput passphrase source (e.g. pass:secret, file:path)
-passoutOutput passphrase destination
-pkeyoptAlgorithm-specific option as name:value pair
-pubkeyOutput the public key alongside the certificate
-puboutOutput the public key in PEM format
-sigfileFile containing the signature to verify
-signSign the input data using the given private key
-subjCertificate subject as /CN=.../O=.../C=... DN string
-textPrint human-readable details
-verifyVerify a signature against the given public key
-x509Output a self-signed certificate instead of a CSR
configutldocs.openssl.org/3.6/man1/openssl-configutl — new in OpenSSL 3.6. Parses a config file and (with -out) re-dumps its linearized, expanded form.
dgstdocs.openssl.org/3.6/man1/openssl-dgst — hashes input, and with -sign/-verify signs or verifies using the classical hash-then-sign shape (RSA/EC/Ed25519 keys in this Studio).
DSADigital Signature Algorithm (FIPS 186) — an older classical signature scheme based on the discrete-log problem, largely superseded by ECDSA/EdDSA in new deployments but still listed by openssl list.
ECElliptic Curve — the OpenSSL algorithm family name for elliptic-curve keys (paired with a named curve like P-256/P-384 via -pkeyopt ec_paramgen_curve). Security rests on the elliptic-curve discrete log problem, also broken by Shor's algorithm.
ED25519RFC 8032 — EdDSA signatures over Curve25519. A classical signature algorithm, distinct from X25519 (key exchange) despite the shared curve.
ED448RFC 8032 — EdDSA signatures over Curve448, the higher-security sibling of Ed25519.
encdocs.openssl.org/3.6/man1/openssl-enc — symmetric encrypt/decrypt. Never supports authenticated modes (GCM/CCM) and the docs say it never will; use openssl-cms for AEAD.
genpkeydocs.openssl.org/3.6/man1/openssl-genpkey — generates a private key (or keypair) for any algorithm the active providers support, classical or post-quantum, with the same command shape.
HKDFRFC 5869 — HMAC-based Extract-and-Expand KDF. Assumes the input is ALREADY a high-entropy secret (unlike PBKDF2/SCRYPT, which assume a human password) — see the KDF concept term.
HMACRFC 2104 — a keyed-hash message authentication code, built from any underlying digest (e.g. HMAC-SHA256). Also usable as a KDF building block (HKDF is HMAC-based).
HSSRFC 8554 — Hierarchical Signature System, LMS's multi-tree extension. Same OpenSSL 3.6 verify-only scope as LMS.
kdfdocs.openssl.org/3.6/man1/openssl-kdf — new in OpenSSL 3.6. Drives HKDF, PBKDF2, SCRYPT, SSKDF and more behind one command; -kdfopt keys are algorithm-specific.
LMSRFC 8554 / NIST SP 800-208 — Leighton-Micali stateful hash-based signatures. OpenSSL 3.6 supports VERIFICATION ONLY; key generation and signing are intentionally out of scope for OpenSSL core (see the "stateful signature" term below).
ML-DSAFIPS 204, Module-Lattice-Based Digital Signature Algorithm. Native in OpenSSL's default provider since 3.5. -44/-65/-87 name the parameter set.
ML-KEMFIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism. Native in OpenSSL's default provider since 3.5. -512/-768/-1024 name the parameter set.
PBKDF2RFC 2898 / PKCS#5 — Password-Based KDF 2. Stretches a human password via repeated HMAC iterations (-kdfopt iter:) — what pkcs12 and enc use internally via -pbkdf2.
pkcs12docs.openssl.org/3.6/man1/openssl-pkcs12 — bundles/unpacks a key + certificate(+ chain) into one password-protected .p12 file. OpenSSL 3.x defaults to AES-256-CBC + PBKDF2; -legacy reverts to RC2/3DES.
pkeydocs.openssl.org/3.6/man1/openssl-pkey — displays/converts a private key and (with -pubout) extracts its public key.
pkeyutldocs.openssl.org/3.6/man1/openssl-pkeyutl — the generic public-key operation command: -sign/-verify (ML-DSA/SLH-DSA, hashing internally) and -encap/-decap (ML-KEM key establishment).
randdocs.openssl.org/3.6/man1/openssl-rand — draws bytes from RAND_bytes(), OpenSSL's CSPRNG. Fails loudly if OS entropy seeding failed, rather than emitting weak output.
reqdocs.openssl.org/3.6/man1/openssl-req — builds a PKCS#10 CSR (-new) or, with -x509 added, a self-signed certificate directly.
RSARivest-Shamir-Adleman — security rests on integer factorization being hard, which is exactly what Shor's algorithm breaks on a quantum computer (see the "Shor's algorithm" term).
SCRYPTRFC 7914 — a memory-hard password-based KDF, more resistant to hardware (ASIC/GPU) brute-forcing than PBKDF2 because it deliberately costs memory as well as CPU time.
SecP256r1MLKEM768A hybrid TLS key-share group combining classical P-256 (secp256r1) with ML-KEM-768.
SecP384r1MLKEM1024A hybrid TLS key-share group combining classical P-384 (secp384r1) with the higher-security ML-KEM-1024.
SLH-DSAFIPS 205, Stateless Hash-Based Digital Signature Algorithm. Native since OpenSSL 3.5; SHA2/SHAKE variants at 128/192/256-bit levels, each in a small-signature (s) or fast-signing (f) form.
SM2A Chinese national-standard elliptic-curve signature/encryption algorithm (GB/T 32918), registered as an alias of the generic EC key manager in this OpenSSL build.
versiondocs.openssl.org/3.6/man1/openssl-version — reports the OpenSSL build in use; -a includes build flags and platform. This Studio runs 3.6.3.
X25519RFC 7748 — a specific Curve25519-based key-exchange algorithm. Appears alone in genpkey (a classical KEX key) and combined with ML-KEM in the hybrid group X25519MLKEM768.
X25519MLKEM768A hybrid TLS key-share group combining classical X25519 with ML-KEM-768 — secure as long as EITHER component holds. OpenSSL 3.5+ defaults new TLS 1.3 connections to this group.
X448RFC 7748 — a specific Curve448-based key-exchange algorithm, the higher-security sibling of X25519. Combined with ML-KEM-1024 in the hybrid group X448MLKEM1024.
X448MLKEM1024A hybrid TLS key-share group combining classical X448 with ML-KEM-1024.
x509docs.openssl.org/3.6/man1/openssl-x509 — displays, converts, or (as a "micro CA") signs X.509 certificates.

AEAD (Authenticated Encryption with Associated Data)A cipher mode (GCM, CCM, ChaCha20-Poly1305) that authenticates as it encrypts. openssl enc has never supported these and the docs say it never will — openssl-cms is the documented path for AEAD.
CSR (Certificate Signing Request)A PKCS#10 request (RFC 2986) containing a public key + subject, produced by req -new, for a CA to sign into a certificate. req -x509 -new skips this and self-signs directly.
KDF (Key Derivation Function)Turns one input (a password, or an existing high-entropy secret) into cryptographic key material. HKDF/SSKDF assume a high-entropy secret already; PBKDF2/SCRYPT assume a human password and add deliberate work factor — mixing them up silently derives a weaker-than-intended key.
PKCS#12A password-protected bundle format holding a private key + certificate (+ chain) in one file — the shape most browsers and app servers actually import, versus loose PEM files.
PKCS#8The standard container format genpkey writes private keys in by default — algorithm-agnostic, which is why the SAME -out flag works whether the key is RSA or ML-DSA.
ProviderOpenSSL 3.x's unit of pluggable algorithm implementations (docs.openssl.org/3.6/man7/openssl-glossary). `openssl list -providers` reporting a provider "active" only means it loaded into the registry — NOT that every algorithm it claims to register actually works (see the Algorithm Explorer's live functional check).
Self-signed certificateA certificate signed by its own private key rather than an external CA — produced by req -x509 -new in one step. Fine for testing/internal use; browsers won't trust it by default.

Composite signatureA single signature combining a classical algorithm (e.g. RSA, ECDSA) with ML-DSA — a hedging strategy like hybrid KEM, but for signatures, from the IETF LAMPS working group's composite-signatures draft work. This build's pkcs11 provider registers 3 such composites (named after "draft-lamps-19" in its own algorithm labels — the revision it was built against), though that provider is not currently functional here.
FIPS 203NIST's Module-Lattice-Based Key-Encapsulation Mechanism Standard — specifies ML-KEM-512/768/1024, including the exact ciphertext and shared-secret sizes this curriculum measured live.
FIPS 204NIST's Module-Lattice-Based Digital Signature Standard — specifies ML-DSA-44/65/87, including the exact key and signature sizes this curriculum measured live.
FIPS 205NIST's Stateless Hash-Based Digital Signature Standard — specifies SLH-DSA's 12 parameter sets (SHA2/SHAKE × 128/192/256 × s/f).
Grover's algorithmA quantum algorithm giving only a QUADRATIC speedup against symmetric ciphers/hash functions — AES-256 keeps ~128-bit security against it. Contrast with Shor's algorithm below.
Harvest-now-decrypt-laterRecording today's classically-encrypted traffic now, to decrypt once a cryptographically relevant quantum computer exists. The reason PQC key establishment (ML-KEM) is being deployed years before such a computer is known to exist.
Hybrid key exchangeCombining a classical group (X25519, P-256/384) with an ML-KEM parameter set in one TLS key-share group (e.g. X25519MLKEM768) — secure as long as EITHER component holds, hedging against an undiscovered weakness in the newer PQC math.
KEM (Key Encapsulation Mechanism)An operation shape where encapsulation GENERATES a fresh shared secret as a side effect (pkeyutl -encap), unlike RSA key transport where the caller picks the secret and encrypts it. ML-KEM is a KEM; RSA is not.
Module lattice problemThe hardness assumption (Module-LWE / Module-SIS) underlying both ML-KEM (FIPS 203) and ML-DSA (FIPS 204) — believed hard even for a quantum computer, unlike factoring or discrete log.
Shor's algorithmA quantum algorithm that breaks integer factorization and discrete log (RSA, ECC, finite-field Diffie-Hellman) in POLYNOMIAL time — an exponential-to-polynomial collapse, not a mild weakening. This asymmetry is why public-key algorithms need replacement while symmetric ones mostly don't.
Stateful hash-based signatureLMS/HSS's security depends on NEVER reusing a one-time key — a property software key generation can't safely guarantee across backups/restores. An OpenSSL maintainer confirmed keygen is intentionally out of core scope for exactly this reason (github.com/openssl/openssl/discussions/29619) — "should be hardware, not software."

Try it

Which OpenSSL command generates an ML-DSA-65 private key — a post-quantum signature key?

Next step

More hands-on tools

The Playground holds the other in-browser tools, grouped by what each one exercises.

OpenSSL Studio

Your first keypair — classical, then post-quantum

Related content