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.