Cryptographic Foundation
Every claim Hashiverse makes about data sovereignty, censorship resistance, and ownership independence is backed by cryptography. This is not window dressing — it is the reason the claims are true. Understanding the cryptographic layer is understanding the foundation everything else is built on.
Identity
A Hashiverse identity is not assigned by a server. It is derived from keys:
ID = Blake3(ed25519_pub || Blake3(Falcon_pub)[0..16] || Blake3(Dilithium_pub)[0..16])Your public ID is a 256-bit hash of three public keys — one classical (Ed25519), two post-quantum (FN-DSA/Falcon and ML-DSA/Dilithium). The 16-byte commitments to the PQ keys bind them into your identity now, before quantum computers are a practical threat. When the quantum migration happens, the upgrade path is already embedded in every identity in the network.
Server identities work the same way, with the additional requirement that the ID must satisfy a proof-of-work condition (a leading-zero prefix in the hash). This makes server identity creation computationally expensive, preventing Sybil attacks on the DHT ring.
The client's Ed25519 private signing key is stored exclusively in the browser's
Web Crypto API secure enclave as a non-extractable
CryptoKey object. The browser exposes only a signing operation — the raw
private key bytes are never accessible to JavaScript, to the WASM module, or to any other
code running on the page. There is no mechanism to export or retrieve the private key once
it has been imported. Signing happens inside the browser's cryptographic layer; the key
never leaves it.
This is a deliberate constraint, not a limitation. Even if the Hashiverse WASM client were fully compromised, an attacker could at most invoke the signing operation on the victim's behalf — they could not steal the key and use it elsewhere.
Source: hashiverse-lib/src/tools/ —
Hash, Id, Signature types;
server_id.rs for server identity PoW.
Post-quantum hybrid signatures
The three-key identity enables a progressive migration path:
- Today: posts are signed with Ed25519. Verification is fast and well-understood.
- When Ed25519 is threatened: migrate primary signing to FN-DSA (Falcon), which has smaller signatures than Dilithium.
- If lattice-based algorithms are later broken: fall back to ML-DSA (Dilithium) as the final layer.
SPHINCS+ was considered and rejected: its signatures are multiple kilobytes, which is prohibitive for a high-throughput post network. The Falcon + Dilithium combination provides two independent lattice-based security assumptions, meaning both would need to be broken simultaneously for the identity to be compromised.
Source: hashiverse-lib/src/tools/ cryptographic primitives;
encoded_post.rs for signature mechanism selection per post.
Hashing
Blake3 is the primary hash function — fast, parallelizable, and suitable for checksums, content addressing, and key derivation. For Proof of Work, the full hashing suite available in the protocol includes Blake2, Blake3, SHA2, SHA3, Whirlpool, Groestl, and Skein. PoW chains multiple algorithms in a pseudo-random sequence, which increases ASIC resistance by requiring efficient co-implementation of several path-dependent algorithms simultaneously.
All hash libraries are compiled with opt-level=3 even in debug builds —
this is configured in the workspace Cargo.toml profile overrides to keep
test suites from being bottlenecked by hash computation.
Encryption at rest
Posts stored on servers are encrypted with ChaCha20-Poly1305. The key is derived from a passphrase that depends on the bucket type:
- User timeline: passphrase is the user's public ID
- Hashtag: passphrase is the lowercase hashtag text (no #)
- Mention: passphrase is the mentioned user's public ID
- Reply: passphrase is the original post's content signature
A custom multi-passphrase encryption scheme, inspired loosely by age, means a
single post that spans multiple contexts — a hashtag post that also mentions a user — can be
decrypted by anyone holding either passphrase. Servers store encrypted bytes they cannot read.
There is no plaintext on server disk.
Source: encoded_post.rs
for post encryption; hashiverse-lib/src/tools/ for the ChaCha20-Poly1305
primitives.
Signatures on everything
Every post is signed by its author. Every server response is signed by the serving server. Every bundle is signed. Signatures are not optional metadata — they are the mechanism by which clients can trust content received from untrusted servers. A client never needs to trust a server; it trusts the cryptographic signature on the content that server delivers.
Two layers of transport security
Hashiverse separates transport encryption from protocol security, and treats them as independent concerns:
Transport layer (TLS): Server-to-server and client-to-server communication runs over HTTPS using TLS certificates issued by Let's Encrypt. Because Hashiverse servers are identified by IP address rather than domain name, the server obtains an IP-only TLS certificate via the ACME protocol. This encrypts traffic in transit and prevents passive eavesdropping on the wire.
Protocol layer (Hashiverse cryptography): TLS alone is not sufficient for a trustless decentralised network — a compromised or malicious server could still serve tampered content over a valid TLS connection. Hashiverse's own cryptography provides the deeper guarantee: every piece of content is signed by its author's keys, posts are encrypted at rest with keys the server never holds, and server identities are bound to proof-of-work commitments. A client does not need to trust any server; it verifies content directly against cryptographic signatures regardless of how it arrived.
TLS handles the network; Hashiverse cryptography handles the truth.