cryptography-review

Cryptographic Review

Comprehensive cryptographic audit covering FIPS 140-3 compliance, European standards (BSI, ANSSI), NIST Special Publications, key management lifecycle, and academic cryptanalysis research. Supersedes the former /fips-audit skill with broader multi-standard coverage.

When to Use

• Before merging any change to crate/crypto/src/ or crate/server/src/core/operations/
• When adding a new algorithm or key type
• When modifying #[cfg(feature = "non-fips")] boundaries
• When changing crate/server/src/openssl_providers.rs
• When modifying key lifecycle state transitions or key management policies
• When evaluating algorithm choices against international compliance requirements

Step 0 — Load Anti-Hallucination Discipline

Read .github/skills/shared/anti-hallucination.md before any analysis. All rules in that file are mandatory for this skill. Do not proceed to Step 1 until you have read it.

Scope Resolution

If a path was provided, scan only that scope. Otherwise scan:

1. crate/crypto/src/ — cryptographic primitives
2. crate/server/src/core/operations/ — per-operation crypto usage
3. crate/server/src/openssl_providers.rs — provider init
4. crate/kmip/src/ — algorithm identifier types
5. crate/clients/clap/src/ — CLI algorithm selection
6. crate/clients/wasm/src/ — WASM crypto calls

---

Step 1 — Algorithm Inventory

Identify every cryptographic algorithm used in the scanned code. For each:

• Algorithm name and key size
• Where it is used (encrypt, sign, derive, hash, MAC, key-wrap, key-encapsulate)
• Whether it is gated with #[cfg(feature = "non-fips")]

Step 2 — Multi-Standard Algorithm Checklist

FIPS 140-3 / NIST Approved (allowed without non-fips gate)

*AES-XTS is non-FIPS in this codebase (non-fips feature).

BSI TR-02102-1 (2024) — Algorithm Recommendations

Cross-check each algorithm found in Step 1 against BSI recommendations:

Reference: BSI TR-02102-1 (2024) — https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf

ANSSI — Recommendations mécanismes cryptographiques (2021)

Cross-check each algorithm against ANSSI requirements:

Reference: ANSSI guide (2021) — https://cyber.gouv.fr/publications/mecanismes-cryptographiques

NOT Approved (must be gated with #[cfg(feature = "non-fips")])

• MD5, SHA1 for any security purpose
• DES, 3DES, RC4, Blowfish, ChaCha20
• AES-XTS (not in FIPS 140-3 approved mode list for this provider)
• Covercrypt, Redis-findex (non-standard, non-FIPS)
• PQC algorithms beyond ML-KEM/ML-DSA/SLH-DSA (pre-standardization)
• EC curves outside P-256/P-384/P-521 (e.g. Curve25519, secp256k1)

Step 3 — Feature Flag Gating Audit

For every non-approved algorithm found:

• Is it gated at the function or module level with #[cfg(feature = "non-fips")]? (correct)
• Is the gate inline inside a function body? (wrong — must be at function level)
• Is the corresponding route registration in start_kms_server.rs wrapped in #[cfg(feature = "non-fips")] { ... }?
• Is the dispatch arm in dispatch.rs gated if the operation is non-FIPS-only?
• Are CLI actions gated in crate/clients/clap/src/?
• Are WASM bindings gated in crate/clients/wasm/src/wasm.rs?

Flag any gate that is placed inside a function body rather than on the function itself:

// WRONG — gate is inline inside function body
fn do_crypto() {
    #[cfg(feature = "non-fips")]
    let _ = md5::compute(data);  // ← wrong position
}

// CORRECT — gate is at function level
#[cfg(feature = "non-fips")]
fn do_crypto_non_fips() {
    let _ = md5::compute(data);
}

Step 4 — Key Size Enforcement

Check all key generation and import operations in crate/server/src/core/operations/:

Flag any operation that accepts key sizes below these minimums without rejecting them.

For BSI compliance, emit a warning (not a blocking finding) for RSA-2048 keys — BSI recommends 3072+ since 2024 but does not yet forbid 2048.

Step 5 — OpenSSL Provider Init

Review crate/server/src/openssl_providers.rs:

• Is apply_openssl_dir_env_if_needed() called before any Provider::try_load() call?
• Is the FIPS provider loaded via OnceLock (single initialization)?
• Is the legacy provider loaded only when non-fips feature is active?
• Are OPENSSL_MODULES and OPENSSL_CONF env vars set before provider init?
• Is there a fallback or error if the FIPS provider fails to load in FIPS mode?

Step 6 — Entropy / RNG

• Is rand::rngs::OsRng (or OpenSSL's CSPRNG) used for all key generation? Flag any use of rand::thread_rng() or rand::random() for security-sensitive operations.
• Are IVs / nonces generated from the CSPRNG, not hardcoded or derived from deterministic sources?
• Are salts for KDFs randomly generated per operation?

Step 7 — CBOM / SBOM Currency

If crate/crypto/build.rs was changed (OpenSSL version update):

• cbom/cbom.cdx.json updated with new algorithm identifiers?
• sbom/ SBOM updated?

Step 8 — Key Management Lifecycle (SP 800-57)

Review key lifecycle state management against NIST SP 800-57 Part 1, Rev. 5:

• State machine completeness: verify the key lifecycle covers all states: Pre-Activation → Active → Deactivated → Compromised → Destroyed / Destroyed-Compromised
• State transitions: verify can_transition_to() (or equivalent) is used to enforce valid transitions — no direct state mutation bypassing the state machine
• Cryptoperiod enforcement: check that keys have configurable cryptoperiods and that expired keys are automatically deactivated (or at minimum, flagged)
• No indefinitely-valid keys: keys without an explicit Deactivation Date or cryptoperiod policy should be flagged as a finding
• Destruction completeness: verify Destroy operation performs cryptographic erasure (zeroization) and not just metadata deletion

Reference: NIST SP 800-57 Part 1, Rev. 5 — Key Management Recommendation

Step 9 — Multi-Standard Compliance Matrix

For each algorithm found in the inventory (Step 1), produce this table:

| Algorithm | FIPS 140-3 | BSI TR-02102-1 (2024) | ANSSI (2021) | SP 800-131A r2 | Notes |
|-----------|-----------|----------------------|--------------|----------------|-------|
| AES-256-GCM | ✅ Approved | ✅ Recommended | ✅ Approved | ✅ Current | — |
| RSA-2048 | ✅ Approved | ⚠️ Deprecated (2024) | ✅ Approved (until 2030) | ⚠️ Legacy use | BSI recommends 3072+ |
| ... | ... | ... | ... | ... | ... |

Flag any algorithm that is:

• Approved by FIPS but deprecated by BSI or ANSSI
• Used in a non-approved mode (e.g., AES-ECB, RSA without padding)
• Missing from one standard's coverage entirely (note as "Not covered")

Step 10 — Academic Research Flags

Cross-reference the algorithms found in the codebase against known cryptanalytic results.

Methodology: search documentation/pandoc/cryptobib/crypto.bib for bib entries related to each algorithm. Only cite bib keys that are actually found via grep — never invent references.

Known attack patterns to check for in the code:

For each flag raised: cite the specific source (bib key from crypto.bib if found, or SECURITY.md entry, or RustSec advisory ID). Never cite a paper that was not found in the bibliography or fetched via URL in this session.

Report Format

## Cryptographic Review: [scope]

### Summary
| Check | Status |
|-------|--------|
| Algorithm inventory | ✅ / ⚠️ N issues |
| Multi-standard checklist | ✅ / ⚠️ N issues |
| Feature flag gating | ✅ / ⚠️ N issues |
| Key size enforcement | ✅ / ⚠️ N issues |
| OpenSSL provider init | ✅ / ⚠️ N issues |
| Entropy / RNG | ✅ / ⚠️ N issues |
| CBOM / SBOM currency | ✅ / ⚠️ N issues / ⏭ N/A |
| Key management lifecycle | ✅ / ⚠️ N issues |
| Multi-standard matrix | ✅ / ⚠️ N divergences |
| Academic research flags | ✅ / ⚠️ N flags |

### Multi-Standard Compliance Matrix
[Table from Step 9]

### Findings
[Severity + description + file + line + fix for each issue]

### Unverified Items
[Items marked REQUIRES MANUAL VERIFICATION per anti-hallucination rules]

Never auto-apply fixes — present for review.