Fase 4: Criptografia e Tesseras Seladas

2026-02-14

Algumas memórias não são para todos. Um diário privado, uma carta para ser +aberta em 2050, um segredo de família selado até que os netos tenham idade +suficiente. Até agora, toda tessera na rede era aberta. A Fase 4 muda isso: +Tesseras agora criptografa conteúdo privado e selado com um esquema +criptográfico híbrido projetado para resistir tanto a ataques clássicos quanto +quânticos.

O princípio continua o mesmo — criptografar o mínimo possível. Memórias públicas +precisam de disponibilidade, não de sigilo. Mas quando alguém cria uma tessera +privada ou selada, o conteúdo agora é trancado por criptografia AES-256-GCM com +chaves protegidas por um mecanismo híbrido de encapsulamento de chaves +combinando X25519 e ML-KEM-768. Ambos os algoritmos precisam ser quebrados para +acessar o conteúdo.

O que foi construído

Encriptador AES-256-GCM (tesseras-crypto/src/encryption.rs) — Criptografia +simétrica de conteúdo com nonces aleatórios de 12 bytes e dados autenticados +associados (AAD). O AAD vincula o texto cifrado ao seu contexto: para tesseras +privadas, o hash do conteúdo é incluído; para tesseras seladas, tanto o hash do +conteúdo quanto o timestamp open_after são vinculados no AAD. Isso significa +que mover texto cifrado entre tesseras com datas de abertura diferentes causa +falha na decriptação — você não consegue enganar o sistema para abrir uma +memória selada antecipadamente trocando o texto cifrado para uma tessera com uma +data de selo anterior.

Mecanismo Híbrido de Encapsulamento de Chaves (tesseras-crypto/src/kem.rs) +— Troca de chaves usando X25519 (Diffie-Hellman clássico em curva elíptica) +combinado com ML-KEM-768 (o KEM pós-quântico baseado em reticulados padronizado +pelo NIST, anteriormente Kyber). Ambos os segredos compartilhados são combinados +via blake3::derive_key com uma string de contexto fixa ("tesseras hybrid kem +v1") para produzir uma única chave de criptografia de conteúdo de 256 bits. Isso +segue a mesma filosofia "dual desde o início" das assinaturas duplas do projeto +(Ed25519 + ML-DSA): se qualquer algoritmo for quebrado no futuro, o outro ainda +protege o conteúdo.

Envelope de Chave Selada (tesseras-crypto/src/sealed.rs) — Encapsula uma +chave de criptografia de conteúdo usando o KEM híbrido, para que apenas o dono +da tessera possa recuperá-la. O KEM produz uma chave de transporte, que é XORed +com a chave de conteúdo para produzir uma chave encapsulada armazenada junto ao +texto cifrado do KEM. Ao desselar, o dono decapsula o texto cifrado do KEM para +recuperar a chave de transporte, depois faz XOR novamente para recuperar a chave +de conteúdo.

Publicação de Chave (tesseras-crypto/src/sealed.rs) — Um artefato assinado +independente para publicar a chave de conteúdo de uma tessera selada após a data +open_after ter passado. O dono assina a chave de conteúdo, o hash da tessera e +o timestamp de publicação com suas chaves duais (Ed25519, com placeholder +ML-DSA). O manifesto permanece imutável — a publicação da chave é um documento +separado. Outros nós verificam a assinatura contra a chave pública do dono antes +de usar a chave publicada para decriptar o conteúdo.

EncryptionContext (tesseras-core/src/enums.rs) — Um tipo de domínio que +representa o contexto AAD para criptografia. Ele vive em tesseras-core e não em +tesseras-crypto porque é um conceito de domínio (não um detalhe de implementação +criptográfica). O método to_aad_bytes() produz serialização determinística: um +byte de tag (0x00 para Private, 0x01 para Sealed), seguido do hash de conteúdo +e, para Sealed, o timestamp open_after como i64 little-endian.

Validação de domínio (tesseras-core/src/service.rs) — +TesseraService::create() agora rejeita tesseras Sealed e Private que não +fornecem chaves de criptografia. Esta é uma validação no nível de domínio: a +camada de serviço garante que você não pode criar uma memória selada sem a +maquinaria criptográfica para protegê-la. A mensagem de erro é clara: "missing +encryption keys for visibility sealed until 2050-01-01."

Atualizações de tipos do core — TesseraIdentity agora inclui um campo +opcional encryption_public: Option<HybridEncryptionPublic> contendo tanto as +chaves públicas X25519 quanto ML-KEM-768. KeyAlgorithm ganhou as variantes +X25519 e MlKem768. O layout do sistema de arquivos de identidade agora +suporta node.x25519.key/.pub e node.mlkem768.key/.pub.

Testes — 8 testes unitários para AES-256-GCM (roundtrip, chave errada, texto +cifrado adulterado, AAD errado, falha de decriptação cross-context, nonces +únicos, mais 2 testes baseados em propriedades para payloads arbitrários e +unicidade de nonces). 5 testes unitários para HybridKem (roundtrip, par de +chaves errado, X25519 adulterado, determinismo do KDF, mais 1 teste baseado em +propriedades). 4 testes unitários para SealedKeyEnvelope e KeyPublication. 2 +testes de integração cobrindo o ciclo de vida completo de tesseras seladas e +privadas: gerar chaves, criar chave de conteúdo, criptografar, selar, desselar, +decriptar, publicar chave e verificar — o ciclo completo.

Decisões de arquitetura

KEM híbrido desde o início: X25519 + ML-KEM-768 segue a mesma filosofia +das assinaturas duplas. Não sabemos quais suposições criptográficas se +manterão ao longo dos milênios, então combinamos algoritmos clássicos e +pós-quânticos. O custo é ~1,2 KB de material de chave adicional por identidade +— trivial comparado às fotos e vídeos em uma tessera.
BLAKE3 para KDF: ao invés de adicionar hkdf + sha2 como novas +dependências, usamos blake3::derive_key com uma string de contexto fixa. O +modo de derivação de chaves do BLAKE3 é especificamente projetado para este +caso de uso, e o projeto já depende do BLAKE3 para hashing de conteúdo.
Manifestos imutáveis: quando a data open_after de uma tessera selada +passa, a chave de conteúdo é publicada como um artefato assinado separado +(KeyPublication), não modificando o manifesto. Isso preserva a natureza +append-only e endereçada por conteúdo das tesseras. O manifesto foi assinado +no momento da criação e nunca muda.
Vinculação AAD previne troca de texto cifrado: o EncryptionContext +vincula tanto o hash de conteúdo quanto (para tesseras seladas) o timestamp +open_after nos dados autenticados do AES-GCM. Um atacante que copie conteúdo +criptografado de uma tessera "selada até 2050" para uma tessera "selada até +2025" vai descobrir que a decriptação falha — o AAD não corresponde mais.
Encapsulamento de chave por XOR: o envelope de chave selada usa um XOR +simples da chave de conteúdo com a chave de transporte derivada do KEM, ao +invés de uma camada adicional de AES-GCM. Como a chave de transporte é um +valor aleatório fresco do KEM e é usada exatamente uma vez, o XOR é +informação-teoricamente seguro para este caso de uso específico e evita +complexidade desnecessária.
Validação de domínio, não validação de storage: a verificação de "chaves +de criptografia ausentes" vive em TesseraService::create(), não na camada de +storage. Isso segue o padrão de arquitetura hexagonal: regras de domínio são +aplicadas na fronteira de serviço, não espalhadas pelos adaptadores.

O que vem a seguir

Fase 4 continuada: Resiliência e Escala — Shamir's Secret Sharing para +distribuição de chaves de herdeiros, NAT traversal avançado (STUN/TURN), +ajuste de performance, auditorias de segurança, empacotamento para sistemas +operacionais
Fase 5: Exploração e Cultura — Navegador público de tesseras por +era/localização/tema/idioma, curadoria institucional, integração com +genealogia, exportação para mídia física (M-DISC, microfilme, papel livre de +ácido com QR)

Tesseras seladas fazem do Tesseras uma verdadeira cápsula do tempo. Um pai agora +pode gravar uma mensagem para o neto que ainda não nasceu, selá-la até 2060 e +saber que o envelope criptográfico vai resistir — mesmo que os computadores +quânticos do futuro tentem abri-lo antes da hora.

+ +