Technical Documentation

Cryptographic specifications and architecture details

OverviewCryptographyArchitectureAudit SystemImplementation

System Overview

HybridCipher is a zero-knowledge, quantum-resistant file encryption and sharing system. It combines post-quantum cryptography (ML-KEM-768) with classical elliptic curve cryptography (X25519) to provide both immediate security and long-term protection against quantum computing attacks.

Design Goals

  • • Zero-knowledge server architecture
  • • Hybrid post-quantum key delivery (classical + PQC)
  • • Seamless access revocation
  • • Cryptographic auditability
  • • No key management burden
  • • Transparent operation (mount as drive)

Security Properties

  • • End-to-end encryption (E2EE)
  • • Forward secrecy via epoch rotation
  • • Post-compromise security
  • • Authenticated encryption (AEAD)
  • • Tamper-proof audit logs
  • • Password-authenticated key exchange (PAKE)

Cryptographic Primitives

Symmetric Encryption

Algorithm:

ChaCha20-Poly1305 (Authenticated Encryption with Associated Data)

Key Size:

256 bits (32 bytes)

Nonce/IV:

96-bit random nonce per encryption operation, generated using a CSPRNG (OS-provided entropy sources)

Authentication Tag:

128-bit Poly1305 tag for integrity and authenticity

Usage:

Each file is encrypted with a unique randomly-generated 256-bit key. This per-file key is then wrapped with the group's epoch key.

Why ChaCha20-Poly1305?

ChaCha20-Poly1305 provides excellent performance across all platforms without requiring hardware acceleration. It's resistant to timing attacks and is widely supported in modern cryptographic libraries.

Post-Quantum Key Encapsulation

Algorithm:

ML-KEM-768 (formerly known as Kyber-768)

Standard:

NIST FIPS 203 (approved August 2024)

Security Level:

Roughly equivalent to AES-192 against quantum attacks (NIST Security Level 3)

Key Sizes:

  • Public key: 1,184 bytes
  • Secret key: 2,400 bytes
  • Ciphertext: 1,088 bytes
  • Shared secret: 32 bytes

Why ML-KEM-768?

ML-KEM-768 provides strong security against quantum computers while maintaining reasonable key sizes. It's based on lattice cryptography (Module-LWE), which has no known efficient quantum algorithms.

Classical Key Exchange

Algorithm:

X25519 (Elliptic Curve Diffie-Hellman over Curve25519)

Security Level:

128-bit security against classical computers

Key Sizes:

  • Public key: 32 bytes
  • Private key: 32 bytes
  • Shared secret: 32 bytes

Why Include Classical Crypto?

Hybrid approach: if ML-KEM-768 has an unknown weakness, X25519 still provides strong protection. X25519 is battle-tested and extremely fast.

Hybrid Key Combiner

Method:

final_key = HKDF-Extract-and-Expand(
  ikm = X25519_shared_secret || ML-KEM_shared_secret,
  salt = (empty),
  info = context_string,
  length = 32
)

Security Rationale:

Simple concatenation followed by HKDF extract (with no salt) and expand (with context string). If either KEM is broken, security depends on the other. Both would need to be broken simultaneously for an attack to succeed.

Note: Join cards accept both HybridKEM (1216 bytes) and X25519-only (32 bytes) invitation keys for compatibility.

Key Derivation

Algorithm:

HKDF-SHA256 (HMAC-based Extract-and-Expand Key Derivation Function)

Standard:

RFC 5869

Usage:

  • Combining hybrid KEM outputs
  • Wrapping keys (KEK derivation)
  • Domain separation in cryptographic operations

Note: Epoch keys and per-file DEKs are randomly generated using CSPRNG, not HKDF-derived from a master key.

Password Authentication

Protocol:

OPAQUE (Asymmetric PAKE)

Standard:

RFC 9497

Properties:

  • Password never sent to server
  • Server learns nothing about password
  • Resistant to pre-computation attacks
  • Protects against server compromise

Why OPAQUE?

Traditional authentication sends password hashes to servers. With OPAQUE, even a compromised server can't help attackers. The server stores an "envelope" encrypted with the password, but never sees the password itself.

System Architecture

Components

┌─────────────────────────────────────────────────────────────┐
│                        Client Device                        │
│  ┌────────────────┐  ┌─────────────────┐  ┌─────────────┐ │
│  │  User Interface│  │  Crypto Engine  │  │  Sync Client│ │
│  │   (GUI/CLI)    │  │  (Encrypt/      │  │             │ │
│  │                │  │   Decrypt)      │  │             │ │
│  └────────────────┘  └─────────────────┘  └─────────────┘ │
│           │                   │                    │        │
│           └───────────────────┴────────────────────┘        │
│                              │                               │
└──────────────────────────────┼───────────────────────────────┘
                               │ TLS 1.3
                               │ (Encrypted Transport)
                               │
┌──────────────────────────────┼───────────────────────────────┐
│                        Zero-Knowledge Server                 │
│  ┌────────────────┐  ┌─────────────────┐  ┌─────────────┐ │
│  │ Authentication │  │   Blob Storage  │  │ Team Manager│ │
│  │   (OPAQUE)     │  │ (Encrypted Data)│  │             │ │
│  └────────────────┘  └─────────────────┘  └─────────────┘ │
│                                                              │
│  ┌────────────────┐  ┌─────────────────┐                   │
│  │  Audit Logger  │  │  Key Directory  │                   │
│  │ (Merkle Trees) │  │ (Public Keys)   │                   │
│  └────────────────┘  └─────────────────┘                   │
└──────────────────────────────────────────────────────────────┘
                               │
                               │ Cloud Provider API
                               │
┌──────────────────────────────┼───────────────────────────────┐
│                    Cloud Storage (Optional)                  │
│                Compatible with any cloud folder                  │
│               (Stores encrypted blobs only)                  │
└──────────────────────────────────────────────────────────────┘

Trust Model

Trusted:

  • Client-side code (open source planned, auditable design)
  • User's devices and local storage
  • TLS infrastructure (certificate authorities)

Untrusted (Adversarial Model):

  • HybridCipher server (honest-but-curious model)
  • Cloud storage providers
  • Network infrastructure
  • Removed team members

Key Principle: The server and cloud providers are assumed to be compromised. Encryption and decryption happen client-side. The server coordinates key delivery and stores encrypted blobs (and epoch keys for group management).

Audit & Accountability System

Audit System Architecture

HybridCipher maintains cryptographically verifiable audit logs using hash chaining for general audit integrity. Merkle trees are used for both membership snapshot roots (roster state verification) and coverage snapshots (file→epoch migration proofs), with signed roots and inclusion proofs for zero-trust verification.

HybridCipher maintains two audit systems:

1. General Audit Trail (Hash-Chained):
   - Entity-level events (user/group/file/epoch actions)
   - Each entry includes SHA-256 hash of current record + previous hash
   - Verified at server startup for tamper detection
   - Stored in PostgreSQL audit_log table

2. Coverage Snapshots (Merkle Trees):
   - File→epoch mappings tracked with Merkle tree commitments
   - Merkle roots are Ed25519-signed and anchored in transparency log
   - Inclusion proofs verify individual file coverage
   - Used to prove migration completeness during epoch cutover

3. Membership Proofs (Production-Ready):
   - Merkle-committed roster state with cryptographic inclusion proofs
   - Salted leaf hashes for privacy (prevents enumeration attacks)
   - Ed25519-signed roots with KMS support (Google Cloud KMS)
   - API endpoints for snapshot retrieval and per-member proof generation

Implementation Details

Libraries & Dependencies

ML-KEM-768:

aws-lc-sys adapter (via mlkem_adapter) - NIST FIPS 203 compliant implementation

X25519:

x25519-dalek (Rust crate) - Well-audited, high-performance elliptic curve cryptography

ChaCha20-Poly1305:

chacha20poly1305 (Rust crate) - Pure Rust implementation with constant-time operations

OPAQUE:

opaque-ke (Rust crate) - RFC 9497 compliant implementation

Key Derivation:

hkdf (Rust crate) - RFC 5869 compliant HKDF-SHA256

Signatures:

ed25519-dalek (Rust crate) - Ed25519 digital signatures

Performance Considerations

Encryption Speed:

  • ChaCha20-Poly1305: ~2-3 GB/s on modern CPUs (no hardware acceleration required)
  • ML-KEM-768 key generation: ~0.5ms per keypair
  • ML-KEM-768 encapsulation: ~0.7ms
  • X25519 key generation: ~0.05ms per keypair
  • X25519 shared secret: ~0.05ms

Storage Overhead:

  • Per-file overhead: less than 1 KB (wrapped keys + metadata)
  • Poly1305 authentication tag: 16 bytes per file
  • Negligible for files >100 KB

Rekeying Performance:

For 10,000 files: ~15 seconds on modern hardware (can run in background)

Security Considerations

  • Encryption and decryption operations occur in client memory
  • Server stores encrypted blobs and coordinates key delivery
  • Ensure server-side storage encryption is configured for defense in depth.
  • Keys are zeroized after use (secure memory wiping)
  • Side-channel protections: constant-time operations where possible
  • CSPRNG seeding from OS entropy sources (/dev/urandom, CryptGenRandom, etc.)
  • Defense in depth: multiple layers (E2EE + TLS + server storage encryption)

Open Source Roadmap

We're committed to transparency. Our core cryptographic implementation will be open sourced once the product reaches stability.

Coming Soon on GitHub

References & Standards