diff options
| author | murilo ijanc | 2026-03-24 21:45:05 -0300 |
|---|---|---|
| committer | murilo ijanc | 2026-03-24 21:45:05 -0300 |
| commit | 01c17c68277ff88fab812920732d9bbe9e6bb571 (patch) | |
| tree | 035398ae34263b981b621c6275835d2cc6847d57 /pt-br/news/phase4-encryption-sealed/index.html | |
| parent | f186b71ca51e83837db60de13322394bb5e6d348 (diff) | |
| download | website-main.tar.gz | |
Remove old Zola-generated content, keep only the essential
landing page with about, contact, and license sections.
Diffstat (limited to 'pt-br/news/phase4-encryption-sealed/index.html')
| -rw-r--r-- | pt-br/news/phase4-encryption-sealed/index.html | 187 |
1 files changed, 0 insertions, 187 deletions
diff --git a/pt-br/news/phase4-encryption-sealed/index.html b/pt-br/news/phase4-encryption-sealed/index.html deleted file mode 100644 index 3cbd9bf..0000000 --- a/pt-br/news/phase4-encryption-sealed/index.html +++ /dev/null @@ -1,187 +0,0 @@ -<!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> |