Parte III · 3 — Mensageria fim-a-fim (Signal)
No TLS, você confia no servidor. Na mensageria fim-a-fim, você não: nem o servidor que entrega as mensagens deve conseguir lê-las. O protocolo do Signal resolve isso — e ainda dá garantias que o TLS não tem: recuperação após compromisso e negação plausível.
3.1 O que muda: end-to-end
No modelo cliente-servidor (TLS), a mensagem é decifrada no servidor. Para chat, isso é inaceitável: o servidor é justamente quem não deve ler. E2EE (end-to-end encryption) cifra na origem e só decifra no destino final — o servidor vê apenas tráfego opaco que roteia.
O desafio: as duas pontas raramente estão online ao mesmo tempo, e a conversa dura meses. Isso exige duas propriedades além das do TLS:
- Forward secrecy — comprometer a chave de hoje não revela mensagens
passadas (como no TLS).
- Post-compromise security (PCS) — se o estado for comprometido hoje, a
segurança se recupera sozinha nas próximas mensagens. O TLS, com sua chave de sessão fixa, não tem isso.
3.2 X3DH: o aperto de mão assíncrono
O X3DH (Extended Triple Diffie-Hellman) resolve o problema de combinar um segredo quando uma das pontas está offline. Cada usuário publica no servidor um conjunto de chaves públicas (identidade + chaves pré-assinadas + um lote de chaves de uso único). Quem inicia a conversa baixa esse pacote e combina o segredo inicial fazendo vários Diffie-Hellman entre as chaves — sem que o outro precise estar online. O servidor só guarda e entrega chaves públicas; nunca vê o segredo.
3.3 O Double Ratchet
Estabelecido o segredo inicial, o Double Ratchet (catraca dupla) gera uma chave nova a cada mensagem — daí o nome "catraca": só avança, nunca volta.
Combina dois mecanismos:
- Catraca simétrica (KDF) — a cada mensagem, uma KDF deriva a próxima chave a
partir da anterior e descarta a antiga. Dá forward secrecy fina: a chave de cada mensagem morre após o uso.
- Catraca Diffie-Hellman — periodicamente, as partes trocam novas chaves
efêmeras e misturam um DH fresco na cadeia. É isto que dá PCS: mesmo que um atacante tenha capturado o estado, o próximo DH o expulsa.
O resultado: comprometer uma chave revela, no máximo, uma mensagem — não a conversa.
3.4 Negação plausível (deniability)
Um efeito desejável da construção baseada em MAC (e não em assinatura): o destinatário não pode provar a terceiros que uma mensagem veio do remetente, porque ele próprio tinha a chave simétrica para forjá-la. Cada um sabe que a mensagem é autêntica; ninguém de fora consegue prová-lo. É o oposto do não-repúdio — e desejado em conversas privadas.
3.5 O retrato completo
A mensageria fim-a-fim costura tudo do compêndio:
| Garantia | Mecanismo | Parte |
|---|---|---|
| Combinar segredo offline | X3DH (vários DH) | II — assimétrica |
| Confidencialidade da mensagem | AEAD | II — simétrica |
| Forward secrecy | catraca simétrica (KDF) | II — hash/KDF |
| Post-compromise security | catraca DH | II — assimétrica |
| Autenticidade sem não-repúdio | MAC | I — objetivos |
Relevância Koder: este é o padrão de referência para qualquer recurso de mensagem privada na Stack (ver o north-star do ktalk como superfície primária). E2EE não é "TLS mais forte" — é um modelo de confiança diferente, em que nem a própria infraestrutura é confiável.
Referência densa: o detalhe de X3DH, do Double Ratchet, do sealed sender e do Noise framework está em
07-protocolos. Fim da Parte III — as primitivas estão coreografadas. A Parte IV — Pós-quântica (em construção) enfrenta o que muda quando o computador quântico quebrar os alicerces assimétricos de tudo isto.