Cryptographic Inventory

This page provides an exhaustive inventory of every cryptographic algorithm used in Open Sesame, where it is used, the key sizes and parameters, and the relevant standards references.

Algorithm Summary

Argon2id

Standard: RFC 9106

Purpose: Derives the master key from a user-supplied password. Used by the Password authentication factor (AuthFactorId::Password in core-types/src/auth.rs).

Parameters:

Implementation: core-crypto/src/kdf.rs, function derive_key_argon2.

Known residual: The Argon2id working memory (19 MiB) resides on the unprotected heap during derivation. This is an upstream limitation of the argon2 crate. See GitHub issue #14.

BLAKE3 Key Derivation

Standard: BLAKE3 specification, KDF mode

Purpose: Derives per-purpose sub-keys from the master key using domain-separated context strings. Each context string is globally unique and hardcoded.

Context strings used in the system:

Implementation: core-crypto/src/hkdf.rs, function derive_32 wrapping blake3::derive_key.

BLAKE3’s KDF mode internally derives a context key from the context string, then uses it as keying material with extract-then-expand semantics equivalent to HKDF.

HKDF-SHA256

Standard: RFC 5869, NIST SP 800-56C

Purpose: Governance-compatible alternative to BLAKE3 key derivation. Used when CryptoConfigToml.hkdf = "hkdf-sha256" (core-config/src/schema_crypto.rs).

Implementation: core-crypto/src/hkdf.rs, function derive_32_hkdf_sha256. Uses the hkdf crate with sha2::Sha256.

The same context strings listed above for BLAKE3 are used as the HKDF info parameter. The salt is extracted from the master key. Output is 32 bytes.

AES-256-GCM (Key Wrapping)

Standard: NIST SP 800-38D, FIPS 197

Purpose: Wraps and unwraps the master key under a key-encryption key (KEK) derived from an authentication factor.

Used in:

• PasswordWrapBlob – master key wrapped under the Argon2id-derived KEK. Stored on disk in the vault metadata.
• EnrollmentBlob – master key wrapped under the SSH agent-derived KEK. Stored on disk for SSH agent factor.

Parameters:

AES-256-CBC + HMAC-SHA512 (SQLCipher)

Standard: FIPS 197 (AES), FIPS 198-1 (HMAC), FIPS 180-4 (SHA-512)

Purpose: SQLCipher page-level encryption for vault databases. Each page in the SQLite database is independently encrypted and authenticated.

Parameters:

Implementation: SQLCipher via the rusqlite crate with the bundled-sqlcipher feature.

Noise IK (IPC Transport)

Standard: Noise Protocol Framework (noiseprotocol.org), pattern IK

Purpose: All inter-daemon communication on the IPC bus. Provides mutual authentication, encryption, and forward secrecy.

Pattern: IK (Initiator knows responder’s static key)

Default cipher suite: Noise_IK_25519_ChaChaPoly_BLAKE2s

Additional binding: The UCred (pid, uid, gid) of the connecting process is bound into the Noise prologue, preventing a process from impersonating another process’s Noise session.

Implementation: core-ipc, using the snow crate. Cipher suite selection is configured via CryptoConfigToml.noise_cipher and CryptoConfigToml.noise_hash in core-config/src/schema_crypto.rs.

Ed25519 (Delegation Signatures)

Standard: RFC 8032

Purpose: Signs DelegationGrant structs to prevent tampering with capability delegations. The 64-byte signature is stored in DelegationGrant.signature (core-types/src/security.rs).

Key size: 256-bit private key, 256-bit public key.

FIPS Path

The following table summarizes FIPS 140 validation status for each algorithm:

For deployments requiring full FIPS 140 compliance, set the crypto profile to governance-compatible:

[crypto]
kdf = "pbkdf2-sha256"
hkdf = "hkdf-sha256"
noise_cipher = "aes-gcm"
noise_hash = "sha256"
audit_hash = "sha256"
minimum_peer_profile = "governance-compatible"

This configuration uses only algorithms with widely available FIPS 140-validated implementations. Open Sesame itself is not a FIPS-validated module; the FIPS boundary is at the cryptographic library level.

Crypto Agility

All cryptographic algorithm selections are config-driven via CryptoConfigToml (core-config/src/schema_crypto.rs). The to_typed() method converts string-based configuration into validated CryptoConfig enum variants.

Adding a new algorithm requires:

1. Adding a variant to the relevant enum in core-types/src/crypto.rs (e.g., KdfAlgorithm::Scrypt).
2. Adding the string mapping in core-config/src/schema_crypto.rs.
3. Implementing the algorithm in the corresponding core-crypto function.

The minimum_peer_profile field in CryptoConfig allows heterogeneous crypto profiles within a federation: each installation selects its own algorithms but can set a floor for what it accepts from peers. This enables gradual migration from one algorithm to another without a coordinated cutover.

PBKDF2-SHA256

Standard: NIST SP 800-132, RFC 8018

Purpose: Governance-compatible alternative to Argon2id for password-based key derivation. Used when CryptoConfigToml.kdf = "pbkdf2-sha256".

Parameters:

Implementation: core-crypto/src/kdf.rs, function derive_key_pbkdf2.

PBKDF2-SHA256 provides FIPS 140 compliance for the KDF layer but is significantly less resistant to GPU/ASIC attacks than Argon2id due to its lack of memory-hardness. It should be selected only when FIPS compliance is a hard requirement.