Como o cofre que nunca sabe sua senha funciona

No ensaio anterior argumentamos que o intermediário ficou desnecessário para um número crescente de funções. Aqui mostramos como isso vira engenharia no TAIVA Vault, sem matemática pesada, com os nomes dos protocolos onde importa.

O problema clássico do armazenamento de senha

Você cria conta. O servidor precisa armazenar algo que prove, no próximo login, que é você. A história tem três respostas progressivas:

1. Texto puro: armazenar a senha como está. Quase ninguém faz, mas vazamentos provam que ainda existe.
2. Hash simples (sha256 sem sal): melhor, mas vulnerável a rainbow table.
3. Hash com sal e função custosa (bcrypt, Argon2id, scrypt): estado da arte por uma década.

Nas três soluções, o servidor recebe sua senha em texto puro no momento do login. Ele aplica a função, compara com o que tem armazenado, libera ou nega. A janela onde a senha existe em memória do servidor pode ser de milissegundos, mas existe. Se houver malware no host, dump de memória, logger acidental, debugger ativo: a senha vaza.

A indústria sempre justificou isso dizendo "confiamos no servidor". Havia razão prática. Não dava para fazer diferente.

PAKE: a saída matemática

PAKE significa Password Authenticated Key Exchange. É uma família de protocolos onde duas partes (cliente e servidor) provam saber a mesma senha sem transmiti-la.

Analogia. Imagine duas pessoas que querem confirmar que conhecem o mesmo endereço sem dizer o endereço. Cada uma calcula a distância da sua casa até o ponto X, depois X até Y, depois Y de volta. Trocam apenas o número final. Se os números bateram, partiram do mesmo lugar. Se não, divergiram no primeiro passo e nenhuma das duas aprende a casa da outra.

OPAQUE-3DH (RFC 9497) é o estado da arte dessa família em 2026. Padronizado pela IETF, revisado por dezenas de criptógrafos, implementado pela Cloudflare na biblioteca @cloudflare/opaque-ts que o TAIVA Vault usa em produção.

O fluxo simplificado:

1. Você digita a senha no navegador.
2. Cliente faz uma operação local com a senha (OPRF blinding), gera um ke1 e envia ao servidor.
3. Servidor não consegue reverter ke1 para senha (propriedade da OPRF).
4. Servidor responde com ke2 baseado em parâmetros próprios mais ke1.
5. Cliente combina ke1, ke2 e a senha local para gerar ke3.
6. Ambos chegam num export_key idêntico de 32 bytes, se a senha estava correta. Se não estava, divergem matematicamente e ninguém aprende nada útil.

Em nenhum momento do protocolo a senha em texto puro sai do navegador. O servidor recebe matemática derivada, opera nela, devolve matemática derivada. Se o handshake fecha, ambos sabem que ambos sabiam a senha. Se não fecha, falha silenciosa.

O wrap híbrido pós-quântico

OPAQUE prova que você sabe a senha. Mas o cofre tem outra função: guardar seus dados cifrados sem que o servidor saiba o que tem dentro.

Para isso, derivamos uma chave de criptografia (DEK, Data Encryption Key) a partir do export_key. Essa DEK nunca sai do navegador em texto puro. É usada localmente para cifrar cada credencial antes de subir pro servidor.

Isso resolveria o problema "servidor lê meus dados", mas abre outro: e se daqui a 15 ou 20 anos computadores quânticos conseguirem quebrar a criptografia atual? A preocupação é real e está documentada pelo NIST, pela NSA e pela comunidade acadêmica. Não é amanhã. É no horizonte de retenção dos seus dados.

A resposta padrão moderna é hibridizar: combinar criptografia clássica (P-256, AES-256) com criptografia pós-quântica (ML-KEM). Se uma das duas matemáticas cair no futuro, a outra ainda segura.

No TAIVA Vault, usamos ML-KEM-1024 (FIPS 203, categoria de segurança NIST 5, padronizado em agosto de 2024) em modo híbrido com a export_key clássica via HKDF-SHA256.

O fluxo:

1. Servidor mantém um par de chaves ML-KEM-1024 de longa duração (seed guardado em vault de segredos isolado).
2. Cliente busca a pubkey do servidor, encapsula um segredo aleatório contra ela, gera um mlKemCt (ciphertext) e um shared secret.
3. Cliente computa hybridKEK = HKDF(export_key || shared_secret, "taiva-opaque-pq-v1").
4. hybridKEK cifra a DEK antes de subir.
5. No login seguinte, o ciclo se repete: cliente envia mlKemCt, servidor decapsula com sua chave privada, devolve o mesmo shared secret, cliente reconstrói hybridKEK.

Mesmo se uma das matemáticas cair, a outra precisa cair também pro material cifrado ser revelado. Estratégia conhecida como defense in depth criptográfico.

MPC 2-de-3: sem ponto único de falha

OPAQUE mais wrap híbrido cuida do conteúdo. Mas tem outra pergunta: e se o nosso servidor for invadido?

Se a DEK inteira ficasse num único servidor (cifrada, mas íntegra), esse servidor seria ponto único de falha. Mesmo cifrada, guardar tudo num lugar só é fragilidade desnecessária.

A solução é Multi-Party Computation (MPC). Dividimos a DEK em pedaços chamados shares, que ficam em servidores diferentes, em jurisdições diferentes. Para reconstruir a chave, precisa de pelo menos N de M shares (threshold).

TAIVA Vault usa esquema híbrido:

1. Cliente faz XOR-split da DEK em share1 e share2 de 32 bytes cada.
2. share1 é cifrado com hybridKEK (a chave derivada do PAKE+ML-KEM) e armazenado no servidor principal como opaqueWrappedDek.
3. share2 é distribuído server-side via Shamir Secret Sharing 2-de-3 entre três nós MPC independentes, em três jurisdições geográficas diferentes.

Para reconstruir a DEK, o cliente precisa:

• Provar a senha via OPAQUE (recupera export_key).
• Decifrar share1 via hybridKEK (recupera primeiro share da DEK).
• Recuperar share2 de pelo menos dois dos três nós MPC.
• Combinar share1 XOR share2 para obter a DEK final.

Se um nó MPC cai, dois continuam servindo (disponibilidade preservada). Se dois caem, o terceiro sozinho não consegue reconstruir share2 (threshold não atingido). Se um nó é comprometido legalmente, o atacante precisa cooperação simultânea de pelo menos mais um nó em outra jurisdição.

Isso elimina o ponto único de falha e também o ponto único de comprometimento legal. Não é cofre absoluto. É arquitetura que multiplica o custo do ataque.

Cadeia auditável ancorada em Bitcoin

Tudo acima protege o conteúdo. Mas resta uma pergunta: como você sabe que nós estamos sendo honestos sobre o que aconteceu no passado?

Cada operação relevante (login, criação de credencial, exportação, solicitação de deleção LGPD) gera uma entrada de log encadeada por hash. Cada entrada contém o hash da entrada anterior, formando uma Merkle chain. Alterar uma entrada antiga muda todos os hashes seguintes em cascata.

Mas ainda assim, em tese, poderíamos reescrever a cadeia inteira se quiséssemos.

Para prevenir isso, ancoramos a cabeça da cadeia em Bitcoin via OpenTimestamps a cada 6 horas. O hash do estado atual fica registrado num bloco Bitcoin público, com timestamp verificável por qualquer observador externo. O custo de reescrever a história depois disso seria reescrever o ledger Bitcoin a partir daquele bloco, ou seja, refazer toda a prova de trabalho desde então, o que ninguém consegue.

Resultado prático: você pode auditar independentemente, com a ferramenta ots verify open source, se nossas afirmações sobre o estado da sua conta numa data X batem com o que estava ancorado em Bitcoin naquele dia.

TLS pós-quântico no transporte

Por fim, o transporte. Mesmo que tudo acima esteja bem, se o canal TLS entre seu navegador e o servidor for quebrado retroativamente, um atacante que tenha gravado o tráfego de hoje pode reproduzir tudo amanhã.

Usamos TLS 1.3 com curva híbrida X25519MLKEM768 (RFC draft adotado por Chrome, Cloudflare e outros em 2024). Mesmo que X25519 caia em vinte anos (quebra clássica improvável), ML-KEM-768 segura. Mesmo que ML-KEM caia (criptanálise pós-quântica improvável), X25519 segura.

Configurado no edge (Caddy e Traefik) com TLS 1.3 mínimo, ciphers fortes, sem fallback fraco.

O que ainda vemos

Nenhum sistema é cofre absoluto. Honestidade técnica importa. O que o TAIVA Vault ainda observa, por design:

• Email cadastrado. Sem isso, não há recovery por OTP.
• Timestamps de operação. Logs de login com IP mascarado após N dias.
• Volume cifrado. Sabemos quantas credenciais tem, qual o tamanho dos blobs. Conteúdo, não.
• Origem aproximada. Geolocalização grossa via IP, retida por período curto para investigar fraude.

O que matematicamente não vemos:

• Sua senha mestra (OPAQUE impede).
• O conteúdo das credenciais (cifrado com DEK derivada client-side).
• O conteúdo das notas seguras (mesma cifragem).
• A própria DEK (existe só na memória do seu navegador durante uso).

Essa fronteira é o ponto. O que precisa ver para funcionar, vê. O que pode esconder e ainda funcionar, esconde. A linha está documentada em whitepaper público, versionada em Git, ancorada em Bitcoin.

Voltando ao ensaio

No post anterior dissemos que o intermediário ficou desnecessário pela engenharia, não pela militância. OPAQUE-3DH, ML-KEM-1024 híbrido, MPC 2-de-3 e cadeia auditável ancorada em Bitcoin são os nomes concretos dessas ferramentas no nosso stack.

Não inventamos nenhuma. Padronizamos integração, testamos contra cenários de ataque conhecidos, deployamos em produção, e documentamos honestamente o que fica fora do escopo.

A pergunta deixa de ser "o que a TAIVA pode fazer com seus dados?". Vira "o que está matematicamente fora do nosso alcance, mesmo se quiséssemos?".

Quanto maior essa segunda lista, mais soberano você é.

Leia também:

• Soberania digital: por que o intermediário ficou desnecessário: o argumento de época que motiva esse design.
• Recovery sem perder soberania: 3 envelopes independentes: como recuperar acesso quando perde a senha mestra, sem entregar o cofre.
• O que mudou no NIST FIPS 203 e por que importa para você: a criptografia pós-quântica que o cofre usa explicada do zero.

TAIVA Vault: cofre digital pessoal com OPAQUE-3DH, ML-KEM-1024 híbrido, MPC 2-de-3 entre três servidores independentes, audit chain ancorado em Bitcoin. Começar trial grátis (14 dias) →