Algorithms and parameter sets
The service offers a small, fixed set of algorithms. This page lists them with their parameter sets, compares them with the recommendations of the technical guideline BSI TR-02102-1, and describes what the service deliberately doesn't do. If your system has to be measured against TR-02102-1, this is where you find the points you must handle yourself.
Terms
- Parameter set: a size level of the same algorithm, such as ML-DSA-65. Larger levels mean larger keys and signatures and a larger security margin.
- Hybrid: a post-quantum algorithm and a classical algorithm used together, so an attacker has to break both.
- Hedged: an ML-DSA signature that mixes fresh randomness into the computation. Two signatures over the same message therefore differ.
Available algorithms
| Algorithm | Standard | Parameter sets | Computed by |
|---|---|---|---|
| AES-256-GCM | NIST SP 800-38D | 32-byte key, 12-byte nonce, 16-byte tag | OpenSSL |
| ML-DSA | FIPS 204 | ML-DSA-44, ML-DSA-65, ML-DSA-87 | OpenSSL |
| ML-KEM | FIPS 203 | ML-KEM-512, ML-KEM-768, ML-KEM-1024 | OpenSSL |
| HKDF-SHA256 | RFC 5869 | output up to 1024 bytes (L4Re) | OpenSSL |
| ChaCha20-Poly1305 | RFC 8439 | only with the chacha20 build feature | OpenSSL |
ML-DSA signs in pure mode, without a context string, using OpenSSL's default, which is hedged. ML-KEM produces a 32-byte shared secret.
Every post-quantum operation goes to OpenSSL. If OpenSSL fails, the request fails with an error code; the service never returns a substitute result. For the OpenSSL version this requires, see Prerequisites.
ChaCha20-Poly1305 isn't approved under FIPS 140-3 and is off by default. The Windows form accepts the build feature but has no operation for it.
How the service compares with BSI TR-02102-1
The 2026-01 edition of BSI TR-02102-1 recommends ML-KEM-768 and ML-KEM-1024 and ML-DSA-65 and ML-DSA-87 for post-quantum use, and only in hybrid form. That leaves three gaps the caller has to close:
| Topic | Service today | What you do |
|---|---|---|
| ML-DSA-44 and ML-KEM-512 | available without restriction | request only ML-DSA-65/-87 and ML-KEM-768/-1024 |
| Pure post-quantum operation | every operation is pure post-quantum | add the classical algorithm yourself and combine the results |
| Combining hybrid secrets | not provided | use a combiner that includes the shared secret, the ciphertext, and the public key, for example per NIST SP 800-227 |
Combining only the two secrets, for example HKDF over K1 || K2, isn't enough. That's why the service's
HKDF operation is no substitute for a hybrid combiner.
Defaults when no level is given
There's exactly one default: in the Windows form, keygen with ML-DSA and no level generates
ML-DSA-65, and keygen with ML-KEM and no level generates ML-KEM-768. Everywhere else, the request
must name the level. The Windows form rejects an unknown level with UNSUPPORTED_ALGORITHM, the L4Re
form with WVDS_ERR_INVALID_HEADER; neither falls back to a different level.
Out of scope
- How keys are created and where they live; see Keys and key storage.
- The byte sizes of keys, signatures, and ciphertexts; see L4Re binary protocol.