Post-Quantum Algorithms

Craton HSM exposes post-quantum key-encapsulation and signature primitives alongside the classical portfolio. Post-quantum support is optional and is guarded by the algorithms.enable_pqc configuration flag; it is automatically disabled when FIPS approved mode is enabled.

Maturity notice

The underlying crates — ml-kem 0.3.0-rc, ml-dsa 0.1.0-rc, slh-dsa 0.2.0-rc — are at release-candidate versions. The NIST specifications they implement (FIPS 203, 204, 205) are final, but:

• Encoded keys, signatures, and KEM ciphertexts produced by an RC release may not interoperate with a later RC or the 1.0 release of the same crate.
• The CryptoBackend API for post-quantum operations may change before Craton HSM 1.0.
• None of the PQC mechanisms are included in the FIPS 140-3 approved set today; CMVP has not yet published certification guidance for FIPS 203/204/205.

Treat post-quantum support as experimental for interoperability. It is production-grade for internal use where both the producer and consumer are pinned to the same Craton HSM version, but long-term interop with third-party implementations should be validated before deployment.

ML-KEM (FIPS 203)

Module-Lattice Key Encapsulation. Replaces classical key exchange with a lattice-based KEM.

Usage: CKM_ML_KEM_* is a key-pair generation mechanism. Encapsulation and decapsulation are performed through C_DeriveKey with the KEM mechanism and the recipient public or private key as the base. The derived key material is the 32-byte shared secret, suitable for seeding an HKDF or direct use as an AES-256 key.

Mechanism numbers

PKCS#11 v3.0 does not yet assign standard mechanism numbers for FIPS 203. Craton HSM uses vendor-defined values:

Consumers that need the eventual OASIS-standardised numbers should wrap Craton HSM behind an alias layer until OASIS publishes them.

ML-DSA (FIPS 204)

Module-Lattice Digital Signature Algorithm. The primary PQC signature scheme standardised by NIST.

ML-DSA is used exactly like any other signature mechanism — C_SignInit / C_Sign or C_SignUpdate sequences. Multi-part streaming is not available; ML-DSA is a single-pass signature over the full message.

Mechanism numbers

SLH-DSA (FIPS 205)

Stateless Hash-Based Signatures. Provides a hash-based fallback should lattice assumptions fail.

SLH-DSA signatures are substantially larger (kilobytes) and slower than ML-DSA; prefer ML-DSA unless a hash-based scheme is specifically required by policy.

Mechanism numbers

Hybrid mechanisms

Hybrid schemes combine a classical and a post-quantum primitive so that the combined output remains secure as long as either primitive is unbroken. Craton HSM exposes two hybrid mechanisms.

X25519 + ML-KEM-768

The hybrid public key encodes the X25519 public key followed by the ML-KEM-768 encapsulation key; the ciphertext encodes the X25519 ephemeral followed by the ML-KEM ciphertext. Cross-implementation interoperability requires matching this exact wire layout — no IETF standard fixes it yet.

ECDSA + ML-DSA

Hybrid signatures double the signature footprint relative to either primitive and double the verification cost. They are intended for transitional deployments where peers may run either classical-only, PQC-only, or hybrid code paths.

Interoperability risk

A brief summary of what may change under each crate's 1.0 release and the likely impact:

When in doubt, pin Craton HSM versions across producer and consumer, or plan a coordinated roll-forward.

FIPS interaction

When algorithms.fips_approved_only = true, all PQC mechanisms are rejected by validate_mechanism_for_policy with CKR_MECHANISM_INVALID and C_GetMechanismList does not advertise them. See FIPS approved mode.

Related

• Cryptography overview
• Classical algorithms
• PKCS#11 mechanisms