Classical Algorithms

This page describes the classical cryptographic algorithms that Craton HSM exposes through the PKCS#11 interface: key sizes, supported mechanisms, whether multi-part streaming is available, and any operational constraints. All algorithms listed here are available with the default RustCrypto backend and with the aws-lc-rs Enterprise backend.

RSA

Constraints

• Keys smaller than 2048 bits are rejected unless algorithms.allow_weak_rsa = true is set. The approved-mode policy always rejects keys below 2048 bits.
• RSA key-size validation strips leading zero bytes from the modulus DER encoding before counting bits, preventing spuriously-oversized-looking keys.
• OAEP uses the MGF1 mask generation function with a hash matching the CKM_RSA_PKCS_OAEP parameter (typically SHA-256).
• PSS salt length defaults to the hash output length; callers may override via the mechanism parameter.

Example

pkcs11-tool --module libcraton_hsm.so --keypairgen \
  --key-type rsa:3072 --label signing-key --pin 87654321
pkcs11-tool --module libcraton_hsm.so --sign \
  --mechanism SHA256-RSA-PKCS --label signing-key \
  --pin 87654321 --input-file msg.bin --output-file msg.sig

ECDSA

Constraints

• CKM_ECDSA expects a caller-provided digest and does not stream.
• Signature encoding is the raw r || s concatenation, matching the PKCS#11 convention.
• Curve parameters are identified by their OID in the CKA_EC_PARAMS attribute; other curves (P-521, secp256k1) are not supported.

ECDH

The shared secret is run through HKDF-SHA256 (SP 800-56C one-step key derivation) before being installed as the derived key's value. The derived key inherits its class and type from the CKA_CLASS / CKA_KEY_TYPE attributes in the caller's template.

EdDSA (Ed25519)

Ed25519 is implemented as PureEdDSA per RFC 8032. CKM_EDDSA doubles as the key-pair-generation mechanism and as the signing mechanism in Craton HSM, in line with common PKCS#11 practice prior to the v3.0 CKM_EC_EDWARDS_KEY_PAIR_GEN split.

X25519

X25519 is not exposed as a standalone derivation mechanism. It is used internally by the hybrid CKM_HYBRID_X25519_ML_KEM_768 mechanism (see Post-quantum).

AES

Constraints

• GCM: 12-byte (96-bit) IVs are required. Per-key nonce counters are maintained via DashMap<key_hash, AtomicU64> to prevent nonce reuse within the process. C_EncryptInit rejects an all-zero IV.
• CBC / CTR: C_EncryptInit rejects an all-zero IV. CBC without padding requires plaintext aligned to the 16-byte block boundary; CKM_AES_CBC_PAD applies PKCS#7 padding.
• Key Wrap: CKM_AES_KEY_WRAP is RFC 3394 AES-KW. CKM_AES_KEY_WRAP_KWP is RFC 5649 AES-KWP (with padding) for wrapping keys of arbitrary byte length.

Example

pkcs11-tool --module libcraton_hsm.so --keygen \
  --key-type aes:32 --label data-key --pin 87654321

HMAC

HMAC is available for use with C_DigestKey to include a key's value in a digest, but direct HMAC computation is driven through the digest mechanisms. The construction uses hmac 0.12 over SHA-256, SHA-384, and SHA-512. PIN hashing uses PBKDF2-HMAC-SHA256 with 600 000 iterations by default (configurable via security.pbkdf2_iterations).

Digests

All digest mechanisms support multi-part streaming (C_DigestInit → C_DigestUpdate* → C_DigestFinal).

Multi-part operation summary

Related

• PKCS#11 mechanism matrix — full capability grid
• Post-quantum algorithms
• Key lifecycle
• FIPS overview