Cryptography, with provenance.
Ed25519 signatures. AES-256-GCM for symmetric. TLS 1.3 for transport. Your keys in your KMS. Post-quantum migration strategy in place. This is the specific cryptographic posture of the Veridra platform.
Cryptographic choices compound over time. The ones we make today will still be verifiable in 2033 when a regulator opens a case about a 2026 decision.
Signature layer — the evidence foundation
Every signed Veridra record uses Ed25519 as the primary signature algorithm. Ed25519 is specified in RFC 8032, has fast verification, small signature size (64 bytes), and resistance to side-channel attacks. ECDSA P-256 is supported for legacy compatibility only, not for new deployments.
Signatures are over RFC 8785 JSON Canonicalization Scheme output — a deterministic serialization that eliminates ambiguity about what exactly was signed. This matters for long-term verifiability: a signature over canonical JSON can be verified years later without guessing at the original byte-for-byte form.
Why Ed25519 specifically
- Fast verification on regulator hardware — an auditor's laptop can verify tens of thousands of signatures per second.
- Small signature size — packs deliver quickly even at scale.
- No nonce reuse failure mode (Ed25519 is deterministic; ECDSA requires careful nonce handling).
- Broad library support across the SDK ecosystem — Python, Node, Go, Java all have well-audited implementations.
- Standardized in RFC 8032, implemented in NIST FIPS 186-5.
Symmetric encryption
For data-at-rest encryption where Veridra holds keys: AES-256-GCM. For mobile and constrained environments: ChaCha20-Poly1305. Key derivation uses HKDF for context binding and Argon2id for password-adjacent material. All authenticated encryption; no unauthenticated encryption modes anywhere in the stack.
Transport
TLS 1.3 only for new deployments, with modern cipher suites (AES-GCM and ChaCha20-Poly1305). TLS 1.2 is permitted only for approved legacy integrations from customers with specific constraints, with a restricted cipher suite list. No SSLv3, no TLS 1.0, no TLS 1.1, no RC4, no 3DES, no export ciphers. Perfect forward secrecy is a hard requirement.
Hashing
SHA-256 as the primary hash for all content addressing, input hashing, and Merkle log construction. SHA-384 and SHA-512 are supported for specific use cases (notably where FIPS 140-3 level 3 requires them in customer-configured deployments).
Key management
Signing keys live in your KMS
Long-lived signing keys never enter Veridra infrastructure. They live in your AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault, or PKCS#11 HSM. Veridra's key-broker service requests signatures over canonicalized records; the KMS performs the signing; the signature comes back and is appended to the decision record. If you revoke the signing grant, Veridra immediately loses the ability to sign new decisions. Your custody; our service.
Short-lived signing grants
Key-broker grants are time-bounded to 10 minutes maximum. Each grant is scoped to a specific signing context. Grant issuance is logged in both your KMS audit trail and Veridra's internal audit log, with cross-verifiable timestamps.
Key rotation
Default rotation is quarterly; customer-configurable up to monthly or as-needed. Pre-rotation signatures remain verifiable using the prior public key (published and cross-signed by the new key). Rotation events themselves are signed and logged to the transparency log, so the rotation record itself is evidence.
Post-quantum strategy
Ed25519 is classically secure but post-quantum vulnerable — like all current asymmetric signature schemes in production. Our strategy is hybrid signatures through a transition window: as NIST-standardized post-quantum signature schemes (ML-DSA / FIPS 204) mature, we will offer parallel signing paths that produce both classical and PQ signatures over the same canonical record. This preserves verifiability of historical records (classical) while adding future-secure signing (PQ) for new records. Timeline aligned with NIST final standards and library maturity.