Fundamentos criptográficos

Cada afirmación de Hashiverse sobre soberanía de los datos, resistencia a la censura e independencia de propiedad está respaldada por criptografía. No es decoración — es la razón por la que esas afirmaciones se sostienen. Comprender la capa criptográfica es comprender los cimientos sobre los que se levanta todo lo demás.

Identidad

Una identidad de Hashiverse no la asigna un servidor. Se deriva de claves: 

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

Tu identificador público es un hash de 256 bits de tres claves públicas — una clásica (Ed25519), dos post-cuánticas (FN-DSA/Falcon y ML-DSA/Dilithium). Los compromisos de 16 bytes con las claves PQ las atan a tu identidad ya hoy, antes de que los ordenadores cuánticos sean una amenaza práctica. Cuando ocurra la migración cuántica, el camino de actualización ya está incrustado en cada identidad de la red.

Las identidades de servidor funcionan igual, con el requisito adicional de que el ID debe satisfacer una condición de proof-of-work (un prefijo de ceros a la izquierda en el hash). Esto hace costosa la creación de identidad de servidor, evitando ataques Sybil sobre el anillo DHT.

La clave privada Ed25519 de firma del cliente se almacena exclusivamente en la enclave segura de la Web Crypto API del navegador como un objeto CryptoKey no extraíble. El navegador expone solo una operación de firma — los bytes en bruto de la clave privada nunca son accesibles a JavaScript, ni al módulo WASM, ni a ningún otro código de la página. No existe mecanismo para exportar o recuperar la clave privada una vez importada. La firma ocurre dentro de la capa criptográfica del navegador; la clave nunca sale de allí.

Es una restricción deliberada, no una limitación. Aunque el cliente WASM de Hashiverse estuviera completamente comprometido, un atacante podría, como mucho, invocar la operación de firma en nombre de la víctima — no podría robar la clave para usarla en otro sitio.

Fuente: hashiverse-lib/src/tools/ — tipos Hash, Id, Signature; server_id.rs para la proof-of-work de identidad de servidor.

Firmas híbridas post-cuánticas

La identidad de tres claves habilita un camino de migración progresivo:

SPHINCS+ se valoró y se descartó: sus firmas pesan varios kilobytes, lo que es prohibitivo para una red de publicaciones de alto rendimiento. La combinación Falcon+Dilithium aporta dos supuestos de seguridad basados en retículos independientes, lo que significa que ambos tendrían que romperse simultáneamente para que la identidad quedara comprometida.

Fuente: hashiverse-lib/src/tools/ primitivas criptográficas; encoded_post.rs para la selección del mecanismo de firma por publicación.

Hashing

Blake3 es la función hash primaria — rápida, paralelizable y adecuada para sumas de comprobación, direccionamiento por contenido y derivación de claves. Para proof-of-work, el conjunto completo de hashes disponibles en el protocolo incluye Blake2, Blake3, SHA2, SHA3, Whirlpool, Groestl y Skein. La proof-of-work encadena varios algoritmos en una secuencia pseudoaleatoria, lo que aumenta la resistencia a los ASIC al exigir la coimplementación eficiente de varios algoritmos dependientes del camino simultáneamente.

Todas las bibliotecas de hash se compilan con opt-level=3 incluso en modo debug — está configurado en las sobrescrituras de perfil del Cargo.toml del workspace para que las suites de pruebas no estén cuelladas por el cómputo de hashes.

Cifrado en reposo

Las publicaciones almacenadas en los servidores se cifran con ChaCha20-Poly1305. La clave se deriva de una passphrase que depende del tipo de bucket:

Un esquema personalizado de cifrado con varias passphrases, vagamente inspirado en age, significa que una única publicación que abarque varios contextos — una con hashtag que también menciona a un usuario — puede ser descifrada por cualquiera que tenga cualquiera de las passphrases. Los servidores guardan bytes cifrados que no pueden leer. No hay texto en claro en el disco del servidor.

Fuente: encoded_post.rs para el cifrado de publicaciones; hashiverse-lib/src/tools/ para las primitivas ChaCha20-Poly1305.

Firmas en todo

Cada publicación la firma su autor. Cada respuesta del servidor la firma el servidor que la sirve. Cada bundle se firma. Las firmas no son metadatos opcionales — son el mecanismo por el cual los clientes pueden confiar en contenido recibido de servidores no fiables. Un cliente nunca necesita confiar en un servidor; confía en la firma criptográfica del contenido que ese servidor entrega.

Dos capas de seguridad de transporte

Hashiverse separa el cifrado de transporte de la seguridad de protocolo y los trata como preocupaciones independientes:

Capa de transporte (TLS): la comunicación servidor-a-servidor y cliente-a-servidor va por HTTPS usando certificados TLS emitidos por Let's Encrypt. Como los servidores de Hashiverse se identifican por dirección IP en lugar de nombre de dominio, el servidor obtiene un certificado TLS solo de IP a través del protocolo ACME. Esto cifra el tráfico en tránsito y evita la escucha pasiva en la línea.

Capa de protocolo (criptografía Hashiverse): TLS por sí solo no basta para una red descentralizada sin confianza — un servidor comprometido o malicioso podría servir contenido manipulado por una conexión TLS válida. La criptografía propia de Hashiverse aporta la garantía más profunda: cada pieza de contenido la firman las claves de su autor, las publicaciones se cifran en reposo con claves que el servidor nunca tiene, y las identidades de servidor están atadas a compromisos de proof-of-work. Un cliente no necesita confiar en ningún servidor; verifica el contenido directamente contra firmas criptográficas, sin importar cómo haya llegado.

TLS se ocupa de la red; la criptografía de Hashiverse se ocupa de la verdad.