Voron — biblioteca de cripto/protocolo — pedido de revisão

Este é o núcleo de cripto e protocolo de mensagens de um pequeno projeto de mensageiro E2EE, extraído para revisão externa. Ele não é o produto inteiro — o cliente Android e a configuração de implantação foram deixados de fora propositalmente; esta é apenas a parte que precisa de atenção.

O que há aqui

• common/ — a própria biblioteca:
  • e2ee/ — X3DH-lite (acordo de chaves assíncrono) + um Double Ratchet por cima, construído sobre Curve25519/ChaCha20-Poly1305/Ed25519/HKDF (primitivas fornecidas pelo JDK, nada artesanal nessa camada).
  • crypto/ — wrappers finos sobre essas primitivas do JDK.
  • group/ — mensagens em grupo via esquema de sender-keys (a abordagem pré-MLS que os primeiros grupos do WhatsApp/Signal usavam), além de um log de eventos em cadeia de hash assinado no lado do cliente para associação/papéis, já que o relay não tem nenhum conceito de grupos.
  • onion/ — um transporte opcional de criptografia em camadas (número fixo de saltos, padding por baldes de tamanho) para impedir que o relay relacione diretamente o IP de uma conexão à sua chave de identidade.
  • client/, transport/, backup/ — o protocolo de rede, o handshake de transporte Noise_IK e um formato de backup criptografado.
• server/ — uma implementação de relay de referência: roteamento store-and-forward, diretório de prekeys, caixa postal offline, o papel de hop onion. Confiança deliberadamente mínima: o relay nunca vê texto puro (plaintext), nunca retém uma mensagem por mais tempo que a entrega e (por design) não tem nenhuma ciência de associação a grupos.
• client/ — um harness de teste de console JVM simples (não é um aplicativo real) usado para exercitar common/server entre si em testes de integração, além de alguns PoCs de exploit independentes (veja abaixo).
• security-audit/ — relatórios de rodadas anteriores de revisão interna, os bugs que encontraram e os que já foram corrigidos. Leia isto antes de reportar algo — há uma chance real de já estar aqui. REPORT.md é o principal; ADVERSARIAL_REVIEW_PAVEL.md é uma rodada posterior, mais restrita; fuzz/ e client/.../exploit/ têm PoCs executáveis, não apenas descrições.

Modelo de ameaça, versão curta

• O relay não é uma parte confiável. Ele roteia texto cifrado e dados de diretório (prekeys publicadas) e é considerado ativamente malicioso, não apenas curioso — vários dos bugs corrigidos em security-audit/ são exatamente "o que um relay hostil pode fazer".
• Sessões 1:1 visam sigilo de encaminhamento (X3DH) e segurança pós-comprometimento (o DH-ratchet por cima). Sessões de grupo usam sender-keys: uma mudança de associação gera novas chaves para todo o grupo, mas uma única sender key comprometida expõe as mensagens daquela época — não há ratchet por mensagem na camada de grupo (não é MLS/TreeKEM completo, um corte de escopo deliberado, documentado em group/GroupCryptoSession.kt).
• O roteamento onion esconde o vínculo IP↔identidade de um relay que vê apenas um hop e preenche frames em baldes de tamanho fixo para que a correlação passiva de tamanho entre hops não desanonimize trivialmente um circuito. Ele não esconde a correlação temporal de um adversário que observa ambas as pontas ao mesmo tempo — isso exigiria tráfego de cobertura / mixing, que não está implementado. Isso é explicitamente apontado em security-audit/REPORT.md e ADVERSARIAL_REVIEW_PAVEL.md, não é algo que esteja sendo escondido.

O que queremos especificamente que seja verificado

• A integração X3DH-lite ↔ Double Ratchet (common/src/main/kotlin/messenger/common/e2ee/) — esta é a única construção criptográfica genuinamente sob medida aqui; tudo abaixo dela é de prateleira. Ela já foi revisada internamente várias vezes (veja security-audit/), mas nunca por alguém de fora deste projeto.
• O modelo de autorização do log de controle do grupo (common/src/main/kotlin/messenger/common/group/GroupControlLog.kt) — uma cadeia de hash assinada no lado do cliente, sem nenhum enforcement por parte do servidor.
• Qualquer coisa na camada de roteamento onion que já não esteja coberta pela ressalva documentada de correlação temporal acima.

Executando

./gradlew test

Projeto Gradle/Kotlin padrão, JDK 17+. Nenhum acesso à rede ou serviços em execução é necessário para a suíte de nível de unidade. security-audit/README.md tem instruções para os PoCs de fuzzing ao vivo do relay e de correlação onion, que precisam de processos locais em execução (nunca aponte nada disso para um host de produção).

O que isto não é

Nenhuma auditoria criptográfica independente foi feita nisto. Tudo em security-audit/ é revisão interna de engenharia — cuidadosa, mas uma auto-revisão, sem respaldo de prova formal e sem histórico profissional/institucional por trás. Trate-o como um ponto de partida para revisão, não uma certificação.