Phase 4: Encryption and Sealed Tesseras

2026-02-14

Some memories are not meant for everyone. A private journal, a letter to be +opened in 2050, a family secret sealed until the grandchildren are old enough. +Until now, every tessera on the network was open. Phase 4 changes that: Tesseras +now encrypts private and sealed content with a hybrid cryptographic scheme +designed to resist both classical and quantum attacks.

The principle remains the same — encrypt as little as possible. Public memories +need availability, not secrecy. But when someone creates a private or sealed +tessera, the content is now locked behind AES-256-GCM encryption with keys +protected by a hybrid key encapsulation mechanism combining X25519 and +ML-KEM-768. Both algorithms must be broken to access the content.

What was built

AES-256-GCM encryptor (tesseras-crypto/src/encryption.rs) — Symmetric +content encryption with random 12-byte nonces and authenticated associated data +(AAD). The AAD binds ciphertext to its context: for private tesseras, the +content hash is included; for sealed tesseras, both the content hash and the +open_after timestamp are bound into the AAD. This means moving ciphertext +between tesseras with different open dates causes decryption failure — you +cannot trick the system into opening a sealed memory early by swapping its +ciphertext into a tessera with an earlier seal date.

Hybrid Key Encapsulation Mechanism (tesseras-crypto/src/kem.rs) — Key +exchange using X25519 (classical elliptic curve Diffie-Hellman) combined with +ML-KEM-768 (the NIST-standardized post-quantum lattice-based KEM, formerly +Kyber). Both shared secrets are combined via blake3::derive_key with a fixed +context string ("tesseras hybrid kem v1") to produce a single 256-bit content +encryption key. This follows the same "dual from day one" philosophy as the +project's dual signing (Ed25519 + ML-DSA): if either algorithm is broken in the +future, the other still protects the content.

Sealed Key Envelope (tesseras-crypto/src/sealed.rs) — Wraps a content +encryption key using the hybrid KEM, so only the tessera owner can recover it. +The KEM produces a transport key, which is XORed with the content key to produce +a wrapped key stored alongside the KEM ciphertext. On unsealing, the owner +decapsulates the KEM ciphertext to recover the transport key, then XORs again to +recover the content key.

Key Publication (tesseras-crypto/src/sealed.rs) — A standalone signed +artifact for publishing a sealed tessera's content key after its open_after +date has passed. The owner signs the content key, tessera hash, and publication +timestamp with their dual keys (Ed25519, with ML-DSA placeholder). The manifest +stays immutable — the key publication is a separate document. Other nodes verify +the signature against the owner's public key before using the published key to +decrypt the content.

EncryptionContext (tesseras-core/src/enums.rs) — A domain type that +represents the AAD context for encryption. It lives in tesseras-core rather than +tesseras-crypto because it's a domain concept (not a crypto implementation +detail). The to_aad_bytes() method produces deterministic serialization: a tag +byte (0x00 for Private, 0x01 for Sealed), followed by the content hash, and for +Sealed, the open_after timestamp as little-endian i64.

Domain validation (tesseras-core/src/service.rs) — +TesseraService::create() now rejects Sealed and Private tesseras that don't +provide encryption keys. This is a domain-level validation: the service layer +enforces that you cannot create a sealed memory without the cryptographic +machinery to protect it. The error message is clear: "missing encryption keys +for visibility sealed until 2050-01-01."

Core type updates — TesseraIdentity now includes an optional +encryption_public: Option<HybridEncryptionPublic> field containing both the +X25519 and ML-KEM-768 public keys. KeyAlgorithm gained X25519 and MlKem768 +variants. The identity filesystem layout now supports node.x25519.key/.pub +and node.mlkem768.key/.pub.

Testing — 8 unit tests for AES-256-GCM (roundtrip, wrong key, tampered +ciphertext, wrong AAD, cross-context decryption failure, unique nonces, plus 2 +property-based tests for arbitrary payloads and nonce uniqueness). 5 unit tests +for HybridKem (roundtrip, wrong keypair, tampered X25519, KDF determinism, plus +1 property-based test). 4 unit tests for SealedKeyEnvelope and KeyPublication. 2 +integration tests covering the complete sealed and private tessera lifecycle: +generate keys, create content key, encrypt, seal, unseal, decrypt, publish key, +and verify — the full cycle.

Architecture decisions

Hybrid KEM from day one: X25519 + ML-KEM-768 follows the same philosophy +as dual signing. We don't know which cryptographic assumptions will hold over +millennia, so we combine classical and post-quantum algorithms. The cost is +~1.2 KB of additional key material per identity — trivial compared to the +photos and videos in a tessera.
BLAKE3 for KDF: rather than adding hkdf + sha2 as new dependencies, we +use blake3::derive_key with a fixed context string. BLAKE3's key derivation +mode is specifically designed for this use case, and the project already +depends on BLAKE3 for content hashing.
Immutable manifests: when a sealed tessera's open_after date passes, the +content key is published as a separate signed artifact (KeyPublication), not +by modifying the manifest. This preserves the append-only, content-addressed +nature of tesseras. The manifest was signed at creation time and never +changes.
AAD binding prevents ciphertext swapping: the EncryptionContext binds +both the content hash and (for sealed tesseras) the open_after timestamp +into the AES-GCM authenticated data. An attacker who copies encrypted content +from a "sealed until 2050" tessera into a "sealed until 2025" tessera will +find that decryption fails — the AAD no longer matches.
XOR key wrapping: the sealed key envelope uses a simple XOR of the content +key with the KEM-derived transport key, rather than an additional layer of +AES-GCM. Since the transport key is a fresh random value from the KEM and is +used exactly once, XOR is information-theoretically secure for this specific +use case and avoids unnecessary complexity.
Domain validation, not storage validation: the "missing encryption keys" +check lives in TesseraService::create(), not in the storage layer. This +follows the hexagonal architecture pattern: domain rules are enforced at the +service boundary, not scattered across adapters.

What comes next

Phase 4 continued: Resilience and Scale — Shamir's Secret Sharing for heir +key distribution, advanced NAT traversal (STUN/TURN), performance tuning, +security audits, OS packaging
Phase 5: Exploration and Culture — Public tessera browser by +era/location/theme/language, institutional curation, genealogy integration, +physical media export (M-DISC, microfilm, acid-free paper with QR)

Sealed tesseras make Tesseras a true time capsule. A father can now record a +message for his unborn grandchild, seal it until 2060, and know that the +cryptographic envelope will hold — even if the quantum computers of the future +try to break it open early.

+ +