Latticra

Home / Cryptographic assurance and key management

FIPS, Keys, Randomness, and Non-Claims

Cryptographic assurance and key management

Latticra records the evidence required before production cryptography, signing, key storage, FIPS/CMVP claims, randomness, or post-quantum migration wording can promote. It does not implement production crypto or grant signing authority.

Current Rule

Crypto metadata is not signing authority.

The baseline names cryptographic module boundaries, approved algorithm and parameter inventories, key lifecycle contracts, randomness review, self-test behavior, sensitive-data handling, and post-quantum planning as prerequisites. Until those records are complete and validated, crypto-facing records remain metadata and non-claim language.

01

Module boundary

Any future production crypto needs a named module boundary, interface inventory, approved algorithms, parameters, and security-strength records.

02

Key lifecycle

Key types, generation, storage, access control, rotation, expiration, zeroization, compromise response, and metadata protection must be explicit.

03

Randomness and self-tests

Entropy source, DRBG or random-bit generator, startup self-tests, continuous checks, and failure behavior require written review.

04

Post-quantum planning

Migration wording needs an inventory of affected algorithms, dependencies, transition rules, and operator-visible non-claims.

Current Snapshot

The baseline exists to keep crypto claims closed.

These fields are a claim boundary. They show that requirements are tracked, while production cryptography, signing authority, and FIPS claims remain unavailable.

cryptographic_assurance_key_management_baseline 1
fips_140_3_boundary_required 1
validated_module_claim_requires_certificate 1
key_lifecycle_contract_required 1
seal_crypto_authority_neutral_current 1
production_crypto_added 0
signing_authority_granted 0
fips_claim_allowed 0

Promotion Gate

No crypto-facing wording can promote without the required evidence.

A future cryptographic capability needs evidence that covers module scope, algorithm choices, key material, randomness, failure behavior, validation status, and public non-claims before it can affect release wording.

Present now

Baseline record, status record, guard script, source references, Seal metadata-only records, and public non-claim wording.

Required before promotion

Module boundary, interface inventory, algorithm and parameter inventory, key lifecycle and storage contract, access control, zeroization, compromise response, entropy and DRBG review, self-test failure behavior, sensitive-data logging review, side-channel review, validation certificate or non-FIPS disclosure, post-quantum inventory, and operator-visible non-claims.

Denied now

Production cryptography, FIPS/CMVP claims, release signing, update signing, receipt signing, key generation, key storage, key derivation, entropy collection, random-bit generation, post-quantum migration claims, and cryptographic module validation claims.

Seal Crypto Boundary

Seal records crypto-facing metadata without becoming crypto enforcement.

Seal can describe verification posture and denied authority, but the current records do not create a production signing path, key store, validated module, or runtime enforcement boundary.

Metadata

Verify backend

The current crypto verify backend status is metadata-only and does not claim production verification.

Verify only

Ed25519 posture

Ed25519 records stay authority-neutral and do not create signing or update authority.

Closed

Signing and key material

Signing, key material handling, key storage, key generation, and release/update signatures remain unavailable.

Closed

Production enforcement

No runtime authority, FIPS claim, CMVP claim, production crypto enforcement, or external endorsement is granted.

Local Commands

Validate the records without enabling crypto behavior.

These commands check that public records, status fields, and safety gates stay aligned. They do not generate keys, sign artifacts, collect entropy, or perform validation submissions.

Crypto baseline

sh scripts/test-cryptographic-assurance-key-management-baseline.sh

High-assurance rollup

sh scripts/test-high-assurance-security-baseline.sh

Runtime authority gate

sh scripts/test-zero-trust-runtime-authority-baseline.sh

Source Records

Use exact records before repeating crypto assurance wording.

Cryptographic assurance and key management baselineFIPS/CMVP claim gates, algorithm inventory, key lifecycle, randomness, post-quantum planning, and no production crypto claims. Crypto assurance statusStatus fields and expected guard output for the cryptographic assurance baseline. High-assurance baselineSource-tracked security posture and future cryptographic control allocation. Seal crypto verify contractMetadata-only verification boundary and unsupported production crypto posture. Seal crypto verify implementationImplementation record for the current crypto verify backend boundary. Seal crypto verify statusStatus field showing the current unsupported crypto verify state. Seal Ed25519 verify statusAuthority-neutral Ed25519 verify posture and non-signing status. Seal overviewReport-only evidence, policy denial, dry-run posture, and authority boundaries. Supply-chain gatesRelease authority, signing, SBOM, update delivery, and runtime authority blockers. Data classification and protectionSensitive-data handling, PII review, minimization, redaction, and customer-data non-claims. Vulnerability management gateKEV/NVD review, exception records, release blockers, and product-security non-claims. Security overviewSafe testing, effect gates, runtime boundary, and security non-claims. Evidence modelPromotion levels, public claim boundaries, and exact source records.