1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
<!DOCTYPE html>
<html lang="pt-br">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Fase 4: Criptografia e Tesseras Seladas — Tesseras</title>
<meta name="description" content="Tesseras agora suporta memórias privadas e seladas com criptografia híbrida pós-quântica — AES-256-GCM, X25519 + ML-KEM-768 e publicação de chaves com bloqueio temporal.">
<!-- Open Graph -->
<meta property="og:type" content="article">
<meta property="og:title" content="Fase 4: Criptografia e Tesseras Seladas">
<meta property="og:description" content="Tesseras agora suporta memórias privadas e seladas com criptografia híbrida pós-quântica — AES-256-GCM, X25519 + ML-KEM-768 e publicação de chaves com bloqueio temporal.">
<meta property="og:image" content="https://tesseras.net/images/social.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:site_name" content="Tesseras">
<!-- Twitter Card -->
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Fase 4: Criptografia e Tesseras Seladas">
<meta name="twitter:description" content="Tesseras agora suporta memórias privadas e seladas com criptografia híbrida pós-quântica — AES-256-GCM, X25519 + ML-KEM-768 e publicação de chaves com bloqueio temporal.">
<meta name="twitter:image" content="https://tesseras.net/images/social.jpg">
<link rel="stylesheet" href="https://tesseras.net/style.css?h=21f0f32121928ee5c690">
<link rel="alternate" type="application/atom+xml" title="Tesseras" href="https://tesseras.net/atom.xml">
<link rel="icon" type="image/png" sizes="32x32" href="https://tesseras.net/images/favicon.png?h=be4e123a23393b1a027d">
</head>
<body>
<header>
<h1>
<a href="https://tesseras.net/pt-br/">
<img src="https://tesseras.net/images/logo-64.png?h=c1b8d0c4c5f93b49d40b" alt="Tesseras" width="40" height="40" class="logo">
Tesseras
</a>
</h1>
<nav>
<a href="https://tesseras.net/pt-br/about/">Sobre</a>
<a href="https://tesseras.net/pt-br/news/">Notícias</a>
<a href="https://tesseras.net/pt-br/releases/">Lançamentos</a>
<a href="https://tesseras.net/pt-br/faq/">FAQ</a>
<a href="https://tesseras.net/pt-br/subscriptions/">Inscrições</a>
<a href="https://tesseras.net/pt-br/contact/">Contato</a>
</nav>
<nav class="lang-switch">
<a href="https://tesseras.net/news/phase4-encryption-sealed/">English</a> | <strong>Português</strong>
</nav>
</header>
<main>
<article>
<h2>Fase 4: Criptografia e Tesseras Seladas</h2>
<p class="news-date">2026-02-14</p>
<p>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.</p>
<p>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.</p>
<h2 id="o-que-foi-construido">O que foi construído</h2>
<p><strong>Encriptador AES-256-GCM</strong> (<code>tesseras-crypto/src/encryption.rs</code>) — 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 <code>open_after</code> 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.</p>
<p><strong>Mecanismo Híbrido de Encapsulamento de Chaves</strong> (<code>tesseras-crypto/src/kem.rs</code>)
— 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 <code>blake3::derive_key</code> 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.</p>
<p><strong>Envelope de Chave Selada</strong> (<code>tesseras-crypto/src/sealed.rs</code>) — 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.</p>
<p><strong>Publicação de Chave</strong> (<code>tesseras-crypto/src/sealed.rs</code>) — Um artefato assinado
independente para publicar a chave de conteúdo de uma tessera selada após a data
<code>open_after</code> 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.</p>
<p><strong>EncryptionContext</strong> (<code>tesseras-core/src/enums.rs</code>) — 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 <code>to_aad_bytes()</code> 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 <code>open_after</code> como i64 little-endian.</p>
<p><strong>Validação de domínio</strong> (<code>tesseras-core/src/service.rs</code>) —
<code>TesseraService::create()</code> 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."</p>
<p><strong>Atualizações de tipos do core</strong> — <code>TesseraIdentity</code> agora inclui um campo
opcional <code>encryption_public: Option<HybridEncryptionPublic></code> contendo tanto as
chaves públicas X25519 quanto ML-KEM-768. <code>KeyAlgorithm</code> ganhou as variantes
<code>X25519</code> e <code>MlKem768</code>. O layout do sistema de arquivos de identidade agora
suporta <code>node.x25519.key</code>/<code>.pub</code> e <code>node.mlkem768.key</code>/<code>.pub</code>.</p>
<p><strong>Testes</strong> — 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.</p>
<h2 id="decisoes-de-arquitetura">Decisões de arquitetura</h2>
<ul>
<li><strong>KEM híbrido desde o início</strong>: 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.</li>
<li><strong>BLAKE3 para KDF</strong>: ao invés de adicionar <code>hkdf</code> + <code>sha2</code> como novas
dependências, usamos <code>blake3::derive_key</code> 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.</li>
<li><strong>Manifestos imutáveis</strong>: quando a data <code>open_after</code> de uma tessera selada
passa, a chave de conteúdo é publicada como um artefato assinado separado
(<code>KeyPublication</code>), 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.</li>
<li><strong>Vinculação AAD previne troca de texto cifrado</strong>: o <code>EncryptionContext</code>
vincula tanto o hash de conteúdo quanto (para tesseras seladas) o timestamp
<code>open_after</code> 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.</li>
<li><strong>Encapsulamento de chave por XOR</strong>: 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.</li>
<li><strong>Validação de domínio, não validação de storage</strong>: a verificação de "chaves
de criptografia ausentes" vive em <code>TesseraService::create()</code>, 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.</li>
</ul>
<h2 id="o-que-vem-a-seguir">O que vem a seguir</h2>
<ul>
<li><strong>Fase 4 continuada: Resiliência e Escala</strong> — 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</li>
<li><strong>Fase 5: Exploração e Cultura</strong> — 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)</li>
</ul>
<p>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.</p>
</article>
</main>
<footer>
<p>© 2026 Tesseras Project. <a href="/atom.xml">News Feed</a> · <a href="https://git.sr.ht/~ijanc/tesseras">Source</a></p>
</footer>
</body>
</html>
|