Fundamentos Criptográficos

Cada afirmação que o Hashiverse faz sobre soberania de dados, resistência à censura e independência de propriedade é sustentada por criptografia. Isto não é decorativo — é a razão pela qual essas afirmações são verdadeiras. Compreender a camada criptográfica é compreender o alicerce sobre o qual tudo o resto é construído.

Identidade

Uma identidade do Hashiverse não é atribuída por um servidor. É derivada de chaves: 

ID = Blake3(ed25519_pub || Blake3(Falcon_pub)[0..16] || Blake3(Dilithium_pub)[0..16])

O teu ID público é um hash de 256 bits de três chaves públicas — uma clássica (Ed25519), duas pós-quânticas (FN-DSA/Falcon e ML-DSA/Dilithium). Os compromissos de 16 bytes para as chaves PQ vinculam-nas à tua identidade desde já, antes de os computadores quânticos serem uma ameaça prática. Quando acontecer a migração quântica, o caminho de atualização já está incorporado em todas as identidades da rede.

As identidades dos servidores funcionam da mesma forma, com o requisito adicional de que o ID tem de satisfazer uma condição de proof-of-work (um prefixo de zeros à cabeça no hash). Isto torna a criação de identidades de servidor computacionalmente cara, prevenindo ataques de Sybil ao anel DHT.

A chave privada de assinatura Ed25519 do cliente é guardada exclusivamente no secure enclave da Web Crypto API do browser, como um objeto CryptoKey não-extraível. O browser expõe apenas uma operação de assinatura — os bytes da chave privada nunca estão acessíveis ao JavaScript, ao módulo WASM, ou a qualquer outro código a correr na página. Não existe mecanismo para exportar ou recuperar a chave privada depois de importada. A assinatura acontece dentro da camada criptográfica do browser; a chave nunca a abandona.

Esta é uma restrição deliberada, não uma limitação. Mesmo que o cliente WASM do Hashiverse estivesse totalmente comprometido, um atacante poderia, no máximo, invocar a operação de assinatura em nome da vítima — não conseguia roubar a chave e usá-la noutro sítio.

Origem: hashiverse-lib/src/tools/ — tipos Hash, Id, Signature; server_id.rs para a PoW de identidade do servidor.

Assinaturas híbridas pós-quânticas

A identidade de três chaves permite um caminho de migração progressivo:

O SPHINCS+ foi considerado e rejeitado: as suas assinaturas têm vários kilobytes, o que é proibitivo para uma rede de publicações de alto débito. A combinação Falcon + Dilithium fornece duas suposições independentes de segurança baseadas em lattices, o que significa que ambas teriam de ser quebradas em simultâneo para a identidade ser comprometida.

Origem: hashiverse-lib/src/tools/ primitivos criptográficos; encoded_post.rs para a seleção do mecanismo de assinatura por publicação.

Hashing

Blake3 é a função de hash primária — rápida, paralelizável, e adequada para checksums, endereçamento por conteúdo e derivação de chaves. Para a Proof of Work, a suite completa de hashing disponível no protocolo inclui Blake2, Blake3, SHA2, SHA3, Whirlpool, Groestl e Skein. A PoW encadeia múltiplos algoritmos numa sequência pseudoaleatória, o que aumenta a resistência a ASICs ao exigir uma coimplementação eficiente de vários algoritmos dependentes do caminho em simultâneo.

Todas as bibliotecas de hash são compiladas com opt-level=3 mesmo nas builds de debug — isto está configurado nos overrides de profile do Cargo.toml do workspace para impedir que as suites de teste fiquem limitadas pela computação de hashes.

Cifragem em repouso

As publicações guardadas nos servidores são cifradas com ChaCha20-Poly1305. A chave é derivada de uma passphrase que depende do tipo de balde:

Um esquema personalizado de cifragem com várias passphrases, vagamente inspirado no age, significa que uma única publicação que abranja vários contextos — uma publicação com hashtag que também menciona um utilizador — pode ser decifrada por qualquer pessoa que possua qualquer uma das passphrases. Os servidores guardam bytes cifrados que não conseguem ler. Não há texto-claro em disco no servidor.

Origem: encoded_post.rs para a cifragem de publicações; hashiverse-lib/src/tools/ para os primitivos ChaCha20-Poly1305.

Assinaturas em tudo

Cada publicação é assinada pelo seu autor. Cada resposta de servidor é assinada pelo servidor que a serve. Cada bundle é assinado. As assinaturas não são metadados opcionais — são o mecanismo pelo qual os clientes podem confiar em conteúdo recebido de servidores não-fiáveis. Um cliente nunca precisa de confiar num servidor; confia na assinatura criptográfica do conteúdo que esse servidor entrega.

Duas camadas de segurança no transporte

O Hashiverse separa a cifragem do transporte da segurança do protocolo, e trata-as como preocupações independentes:

Camada de transporte (TLS): A comunicação servidor-a-servidor e cliente-a-servidor corre sobre HTTPS usando certificados TLS emitidos pelo Let's Encrypt. Como os servidores Hashiverse são identificados por endereço IP em vez de nome de domínio, o servidor obtém um certificado TLS apenas para IP através do protocolo ACME. Isto cifra o tráfego em trânsito e impede a escuta passiva no fio.

Camada de protocolo (criptografia do Hashiverse): O TLS por si só não é suficiente para uma rede descentralizada sem confiança — um servidor comprometido ou malicioso poderia ainda assim servir conteúdo adulterado sobre uma ligação TLS válida. A criptografia própria do Hashiverse fornece a garantia mais profunda: cada peça de conteúdo é assinada pelas chaves do seu autor, as publicações são cifradas em repouso com chaves que o servidor nunca tem, e as identidades dos servidores estão vinculadas a compromissos de proof-of-work. Um cliente não precisa de confiar em nenhum servidor; verifica o conteúdo diretamente contra assinaturas criptográficas, independentemente da forma como chegou.

O TLS trata da rede; a criptografia do Hashiverse trata da verdade.