Cryptography
On this page
- Dual-Hash Strategy
- When to Use Each Hash
- Use SHA-256 (ChainHash)
- Use BLAKE3 (InternalHash)
- SHA-256 Implementation
- BLAKE3 Implementation
- Encryption
- Symmetric Encryption (AES-256-GCM)
- Alternative: ChaCha20-Poly1305
- Digital Signatures (Ed25519)
- Key Hierarchy (Envelope Encryption)
- Master Key
- KEK (Key Encryption Key)
- DEK (Data Encryption Key)
- Key Rotation
- Zeroization
- Constant-Time Operations
- Random Number Generation
- Performance Benchmarks
- Security Considerations
- All-Zero Detection
- Key Stretching (Future)
- Testing
- Compliance
- Related Documentation
Kimberlite’s cryptographic primitives and their usage patterns.
Dual-Hash Strategy
Kimberlite uses two hash algorithms for different purposes:
| Type | Algorithm | Purpose | Performance | FIPS |
|---|---|---|---|---|
ChainHash | SHA-256 | Compliance paths, audit trails, exports | 500 MB/s | FIPS 180-4 |
InternalHash | BLAKE3 | Content addressing, Merkle trees, dedup | 5+ GB/s | Not approved |
When to Use Each Hash
match purpose
Selection by Use Case:
Use SHA-256 (ChainHash)
- Log hash chains (tamper-evident audit trail)
- Checkpoint hashes (compliance exports)
- Digital signatures (signing audit trails)
- External verification (regulators need FIPS-approved)
- Cross-tenant data sharing proofs
Use BLAKE3 (InternalHash)
- Content addressing (deduplication)
- Merkle tree construction (internal indexes)
- Cache keys (content-addressed storage)
- Internal integrity checks (not externally verified)
SHA-256 Implementation
use ;
Properties:
- Algorithm: SHA-256 (FIPS 180-4)
- Output: 32 bytes (256 bits)
- Performance: ~500 MB/s on single core
- Security: Collision-resistant (2^128 operations)
- Use case: Compliance-critical paths
BLAKE3 Implementation
use blake3;
// For large data, use parallel hashing
Properties:
- Algorithm: BLAKE3
- Output: 32 bytes (256 bits)
- Performance: 5-15 GB/s (single core), 15+ GB/s (parallel)
- Security: Collision-resistant (2^128 operations)
- Use case: Internal hot paths
Encryption
Symmetric Encryption (AES-256-GCM)
Used for encrypting data at rest:
use ;
use ;
Properties:
- Algorithm: AES-256-GCM
- Key size: 256 bits (32 bytes)
- Nonce size: 96 bits (12 bytes)
- Authentication: Built-in (AEAD)
- Performance: Hardware-accelerated (Intel AES-NI)
Alternative: ChaCha20-Poly1305
For platforms without AES-NI:
use ;
use ;
Use ChaCha20-Poly1305 when:
- No AES-NI hardware acceleration
- ARM or RISC-V platforms
- Mobile devices
Digital Signatures (Ed25519)
Used for signing audit trails and non-repudiation:
use ;
Properties:
- Algorithm: Ed25519 (EdDSA)
- Key size: 32 bytes (public and private)
- Signature size: 64 bytes
- Performance: ~50k signs/sec, ~25k verifies/sec
- Use case: Audit trail signing, non-repudiation
Key Hierarchy (Envelope Encryption)
┌─────────────┐
│ Master Key │ Stored in HSM/KMS
└──────┬──────┘
│
▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ KEK_A │ │ KEK_B │ │ KEK_C │ Per-tenant
│ (wrapped) │ │ (wrapped) │ │ (wrapped) │ Key Encryption Keys
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ DEK_A │ │ DEK_B │ │ DEK_C │ Per-tenant
│ (encrypts) │ │ (encrypts) │ │ (encrypts) │ Data Encryption Keys
└─────────────┘ └─────────────┘ └─────────────┘
Master Key
Stored in HSM or KMS (AWS KMS, HashiCorp Vault, etc.):
KEK (Key Encryption Key)
Per-tenant key that encrypts the DEK:
DEK (Data Encryption Key)
Per-tenant key that encrypts actual data:
Key Rotation
Rotate KEK without re-encrypting all data:
Zeroization
Keys are zeroized when dropped:
use ;
This prevents keys from leaking through:
- Memory dumps
- Core dumps
- Swap files
- Debuggers
Constant-Time Operations
Use constant-time comparisons for secrets:
use ConstantTimeEq;
Never use == for secret comparison (vulnerable to timing attacks).
Random Number Generation
Use cryptographically secure RNG:
use RngCore;
// Or use getrandom directly (lower-level)
Never use:
rand::random()withoutthread_rng()(may not be cryptographically secure)- Timestamps as nonces (predictable)
- Sequential counters as nonces (predictable)
Performance Benchmarks
On Intel i9 (single core):
| Operation | Throughput | Latency |
|---|---|---|
| SHA-256 hash | 500 MB/s | ~2 µs/KB |
| BLAKE3 hash | 5 GB/s | ~0.2 µs/KB |
| BLAKE3 parallel | 15 GB/s | ~0.07 µs/KB |
| AES-256-GCM encrypt | 2 GB/s | ~0.5 µs/KB |
| AES-256-GCM decrypt | 2 GB/s | ~0.5 µs/KB |
| Ed25519 sign | 50k/sec | ~20 µs |
| Ed25519 verify | 25k/sec | ~40 µs |
Security Considerations
All-Zero Detection
Detect all-zero keys (security vulnerability):
Key Stretching (Future)
For password-derived keys, use Argon2:
// Planned for v0.6.0
Testing
Cryptography is tested exhaustively:
- Unit tests: Each primitive (hash, encrypt, sign)
- Property tests: Round-trip encryption/decryption
- Known-answer tests: NIST test vectors for SHA-256, AES-GCM
- VOPR scenarios: Byzantine attacks test cryptographic validation
See Testing Overview.
Compliance
Kimberlite’s cryptography supports compliance:
| Framework | Requirement | Kimberlite Support |
|---|---|---|
| HIPAA | Encryption at rest | AES-256-GCM per-tenant |
| HIPAA | Encryption in transit | TLS 1.3 |
| FIPS 140-2 | Approved algorithms | SHA-256, AES-256 |
| SOC 2 | Key management | Envelope encryption + KMS |
| GDPR | Right to erasure | Delete KEK → data unrecoverable |
Related Documentation
- Multi-tenancy - Per-tenant encryption
- Compliance - Cryptographic guarantees
- Data Model - Hash chains in the log
Key Takeaway: Kimberlite uses a dual-hash strategy (SHA-256 for compliance, BLAKE3 for performance) and envelope encryption (master key → KEK → DEK) for per-tenant cryptographic isolation.