Purpose
This policy defines approved cryptographic algorithms, key management practices, and security requirements for cryptographic operations in the Provii platform.
Cryptographic Standards
Zero knowledge Proofs
Algorithm: Groth16 Curve: BLS12-381 pairing-friendly elliptic curve Library: bellman 0.14 Use: Age verification proofs
Rationale: Industry-standard, well-audited, optimal proof size
Commitments
Algorithm: Pedersen commitments Curve: Jubjub (embedded in BLS12-381) Library: jubjub 0.10 Use: Hiding date-of-birth in credentials; commitment opened inside ZKP circuit
Rationale: Perfectly hiding, computationally binding; compatible with Groth16 circuit over BLS12-381
Digital Signatures
Credential Signing:
- Algorithm: RedJubjub (custom variant)
- Curve: Jubjub (embedded in BLS12-381)
- Library: redjubjub 0.8
- Use: Issuer signs age credentials
Issuer Attestation:
- Algorithm: Ed25519
- Library: ed25519-dalek 2.x
- Use: Issuers sign attestation payloads proving user identity verification
API Authentication:
- Algorithm: HMAC-SHA256
- Key size: 256 bits minimum
- Use: Expert relying party API authentication (provii-verifier, provii-issuer); also used in provii-verifier hosted mode for session token signing and internal service communication (hosted mode RP auth uses pk_ keys + Origin validation)
WebAuthn Verification:
- Algorithm: ECDSA over P-256 (NIST curve)
- Library: @simplewebauthn/server (TypeScript, admin-portal)
- Use: WebAuthn passkey verification in admin-portal
API Key Hashing
Algorithm: Argon2id (RFC 9106) Library: argon2 0.5 Use: Hashing API keys at rest in provii-verifier and provii-issuer; designed so that stored key material cannot feasibly be reversed
Envelope Encryption
Algorithm: AES-256-GCM Library: aes-gcm 0.10 Use: Envelope encryption of HMAC secrets at rest in KV storage; Master Encryption Key (MEK) held in Cloudflare Secrets Store, Data Encryption Keys (DEK) stored alongside encrypted secrets
Hashing
Approved Algorithms:
- BLAKE2 / BLAKE2s (preferred for ZKP)
- SHA-256 (API authentication, checksums)
- SHA-384 (SRI hashes for browser artifacts)
Prohibited: MD5, SHA-1 (cryptographically broken)
Exception: HMAC-SHA1 is permitted exclusively for YubiKey officer authentication in the provii-issuer. This hardware-enforced constraint cannot be changed as YubiKey 5 series implements HMAC-SHA1 in firmware. The HMAC construction mitigates SHA-1’s collision weaknesses.
Transport Encryption
TLS 1.3 preferred for all external communications
- Minimum: TLS 1.2 (permitted if TLS 1.3 unavailable)
- Cloudflare handles TLS termination
- Certificate management: Automatic (Cloudflare Universal SSL)
Data at Rest
Full disk encryption required:
- macOS: FileVault (AES-256)
- Windows: BitLocker (AES-256)
- Linux: LUKS (AES-256)
Cloudflare KV:
- Encrypted at rest by Cloudflare
- Transparent to applications
Key Management
Signing Key Lifecycle
Generation:
- Generated using cryptographically secure random number generator
- Offline generation preferred
- Ceremony documented (who, when, how)
- Verification key published to JWKS
Storage:
- Production: Cloudflare Workers KV with AES-256-GCM envelope encryption; Master Encryption Key (MEK/KEK) held in Cloudflare Secrets Store, separate from encrypted signing keys
- Backup: Encrypted offline storage (physical security)
- Never in source code or logs
Rotation:
- Schedule: Annually
- Trigger: On compromise or suspected compromise
- Process: Generate new key, update JWKS, mark old key status as Deprecated in KV storage
- Grace period: 30 days for relying parties to update
Destruction:
- Cryptographic erasure (overwrite with random data)
- Physical destruction for offline backups (after retention period)
HMAC Secrets
Generation: Cryptographically secure random (256 bits minimum) Storage: Cloudflare KV with AES-256-GCM envelope encryption; Master Encryption Keys held in Cloudflare Secrets Store Rotation: Annually or on compromise Distribution: Secure channel only (never email)
API Keys
Cloudflare API Tokens:
- Scoped minimally (specific permissions only)
- Stored in GitHub Secrets (for CI/CD) or password manager
- Rotation: Annually or on suspected compromise
GitHub Personal Access Tokens:
- Scoped to required repos/actions only
- Expiration: 90 days maximum
- Stored in password manager
- Rotation: At expiration or on compromise
Cryptographic Implementation
Development Guidelines
Use established libraries:
- Never implement cryptography from scratch
- Use well-audited, maintained libraries
- Keep dependencies updated
Approved Libraries (Rust):
- bellman, bls12_381, jubjub, redjubjub (ZKP and signature primitives)
- ed25519-dalek (Ed25519 attestation signatures)
- blake2, sha2, sha1 (sha1 for YubiKey HMAC only)
- hmac, hkdf (HMAC-SHA256 authentication, key derivation)
- aes-gcm (AES-256-GCM envelope encryption for secrets at rest)
- argon2 (Argon2id for API key hashing)
- subtle (constant-time comparisons)
- zeroize (secret memory erasure)
- rand, rand_core, getrandom (cryptographically secure random)
- p256, ecdsa (P-256 ECDSA primitives, available for future use)
Approved Libraries (JavaScript/TypeScript):
- @simplewebauthn/server (WebAuthn passkey verification in admin-portal)
- Web Crypto API (browser)
- Node.js crypto module
Testing
Required for cryptographic code:
- Unit tests (correctness)
- Property-based tests (proptest)
- Fuzzing (cargo-fuzz)
- Known-answer tests (test vectors)
Never:
- Use weak RNGs for crypto (Math.random, etc.)
- Implement custom crypto without expert review
- Disable crypto for debugging
Quantum Resistance
Current Status: Algorithms are NOT quantum-resistant
Monitoring: Track NIST post-quantum standardisation Timeline: Plan migration when post-quantum standards mature Estimated: 2030-2035 timeframe for practical quantum threat
Near-term: BLS12-381 provides 128-bit security, sufficient for foreseeable future
Compliance
- Australian Signals Directorate (ASD) guidance reviewed
- NIST SP 800-series consulted
- Industry best practices followed
Related Documents
- provii-crypto documentation
- Statement of Applicability - Control A.8.24 (Use of Cryptography)
- Access Control Policy
Document Information
- Version. 1.1
- Effective Date. 2025-01-13
- Last Updated. 2026-05-21
- Owner. ISMS Owner
- Maintained By. Cryptography Specialist
- Review Frequency. Annually
- Next Review. 2026-11-21
- Classification. Public