OpenSSL Studio / OpenSSL Studio

What you will do: Pick the Learn, Explore or Workbench tab; in the Workbench choose a command category such as genpkey, req, x509, dgst, kem or enc, set its parameters, press Run Command and read the terminal output and logs.

Worked example: Choose the preset Generate ML-DSA-65 key, which runs openssl genpkey with the ML-DSA-65 algorithm and writes ml-dsa-65.key into the file manager, ready for a self-signed certificate.

Runtime and privacy: The cryptographic exercise runs in this browser. Review the site privacy terms before entering sensitive material; use synthetic inputs for learning and evaluation.

Browse all Crypto Lab tools

For your role

Developer / Engineer: Run the eleven Learn lessons from Your first keypair to the Capstone, then open Workbench: the Command Preview shows the openssl invocation for each form field, and Edit OpenSSL Config exposes the openssl.cnf behind it.
Security Architect: Lessons L4 (key establishment without classical exchange), L7 (key derivation) and L8 (packaging keys) are the design choices; the Explore tab's Query this build lists which algorithms this OpenSSL build supports.
Researcher / Academic: Lesson L5, An honest LMS, is a claim you can check yourself; the Explore tab's Algorithm Explorer and the glossary's commands and flags are the reference for reproducing each lesson at a terminal.
Certification & Validation Engineer: Lesson L5, An honest LMS, and the Explore tab's Query this build show what this OpenSSL build actually supports; the build is educational and not FIPS-validated, so use it to reproduce a vector, not as evidence.
IT Ops / DevOps: Use the Workbench's Quick Start, Key Generation, CSR and Certificate forms with Command Preview open: the commands are what your scripts will run, and lesson L10 demystifies the config files they read.

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

In the Workbench, change the key algorithm and watch the Command Preview. What is the studio teaching?

Next step

Put it in your report

Your readiness report is where the results of the Playground tools become recommendations.

Next in OpenSSL Studio

API Security & JWT Workshop S/MIME & CMS Workshop

OpenSSL Studio / OpenSSL Studio

Your first keypair — classical, then post-quantum

Related content