Cryptografische basis

Elke claim die Hashiverse maakt over datasoevereiniteit, weerstand tegen censuur en onafhankelijkheid van eigendom wordt gerugsteund door cryptografie. Dit is geen versiering — het is de reden dat de claims waar zijn. De cryptografische laag begrijpen is de basis begrijpen waarop al het andere gebouwd is.

Identiteit

Een Hashiverse-identiteit wordt niet door een server toegekend. Hij wordt afgeleid van sleutels: 

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

Jouw publieke ID is een 256-bits hash van drie publieke sleutels — één klassieke (Ed25519), twee post-quantum (FN-DSA/Falcon en ML-DSA/Dilithium). De 16-byte verbintenissen aan de PQ-sleutels binden deze nu al in jouw identiteit, voordat quantumcomputers een praktische bedreiging zijn. Wanneer de quantummigratie gebeurt, is het opgradepad al ingebed in elke identiteit in het netwerk.

Server-identiteiten werken op dezelfde manier, met de aanvullende vereiste dat het ID moet voldoen aan een proof-of-work-voorwaarde (een prefix met leidende nullen in de hash). Dit maakt het aanmaken van server-identiteiten computationeel duur en voorkomt Sybil-aanvallen op de DHT-ring.

De Ed25519-privé-ondertekeningssleutel van de client wordt uitsluitend opgeslagen in de secure enclave van de Web Crypto API van de browser, als een niet-extraheerbaar CryptoKey-object. De browser stelt alleen een ondertekeningsoperatie beschikbaar — de ruwe privé-sleutelbytes zijn nooit toegankelijk voor JavaScript, voor de WASM-module of voor enige andere code die op de pagina draait. Er is geen mechanisme om de privé-sleutel te exporteren of op te halen zodra hij is geïmporteerd. Het ondertekenen gebeurt binnen de cryptografische laag van de browser; de sleutel verlaat die laag nooit.

Dit is een bewuste beperking, geen tekortkoming. Zelfs als de Hashiverse WASM-client volledig zou worden gecompromitteerd, zou een aanvaller hooguit de ondertekeningsoperatie namens het slachtoffer kunnen aanroepen — hij zou de sleutel niet kunnen stelen en elders gebruiken.

Bron: hashiverse-lib/src/tools/ — Hash, Id, Signature types; server_id.rs voor PoW van server-identiteit.

Post-quantum hybride handtekeningen

De drie-sleutel-identiteit maakt een progressief migratiepad mogelijk:

SPHINCS+ werd overwogen en verworpen: zijn handtekeningen zijn meerdere kilobytes, wat onhaalbaar is voor een hoog-doorvoer-berichtennetwerk. De combinatie Falcon + Dilithium biedt twee onafhankelijke roostergebaseerde beveiligingsaannames, wat betekent dat beide tegelijk gebroken zouden moeten worden om de identiteit te compromitteren.

Bron: hashiverse-lib/src/tools/ cryptografische primitieven; encoded_post.rs voor selectie van het handtekeningmechanisme per bericht.

Hashing

Blake3 is de primaire hash-functie — snel, parallelliseerbaar en geschikt voor checksums, inhouds-adressering en sleutelafleiding. Voor Proof of Work omvat de volledige hash-suite die in het protocol beschikbaar is Blake2, Blake3, SHA2, SHA3, Whirlpool, Groestl en Skein. PoW ketent meerdere algoritmen in een pseudo-willekeurige volgorde, wat de weerstand tegen ASIC's vergroot door efficiënte co-implementatie van meerdere pad-afhankelijke algoritmen tegelijk te vereisen.

Alle hash-bibliotheken worden gecompileerd met opt-level=3 zelfs in debug-builds — dit is geconfigureerd in de profile overrides van de workspace Cargo.toml om te voorkomen dat testsuites een knelpunt worden door hash-berekeningen.

Versleuteling in rust

Berichten die op servers worden opgeslagen zijn versleuteld met ChaCha20-Poly1305. De sleutel wordt afgeleid van een wachtwoordzin die afhangt van het bucket-type:

Een aangepast multi-wachtwoordzin versleutelingsschema, losjes geïnspireerd op age, betekent dat een enkel bericht dat meerdere contexten omspant — een hashtag-bericht dat ook een gebruiker noemt — kan worden ontsleuteld door iedereen die een van beide wachtwoordzinnen bezit. Servers slaan versleutelde bytes op die ze niet kunnen lezen. Er is geen leesbare tekst op de schijf van de server.

Bron: encoded_post.rs voor berichtversleuteling; hashiverse-lib/src/tools/ voor de ChaCha20-Poly1305-primitieven.

Handtekeningen op alles

Elk bericht wordt door zijn auteur ondertekend. Elke serverreactie wordt door de bedienende server ondertekend. Elke bundle wordt ondertekend. Handtekeningen zijn geen optionele metadata — ze zijn het mechanisme waarmee clients inhoud die van niet-vertrouwde servers wordt ontvangen kunnen vertrouwen. Een client hoeft een server nooit te vertrouwen; hij vertrouwt de cryptografische handtekening op de inhoud die de server levert.

Twee lagen transportbeveiliging

Hashiverse scheidt transportversleuteling van protocolbeveiliging en behandelt ze als onafhankelijke aandachtspunten:

Transportlaag (TLS): Server-naar-server- en client-naar-server-communicatie loopt over HTTPS met TLS-certificaten uitgegeven door Let's Encrypt. Omdat Hashiverse-servers worden geïdentificeerd door IP-adres in plaats van domeinnaam, verkrijgt de server een TLS-certificaat voor alleen IP via het ACME-protocol. Dit versleutelt verkeer tijdens transport en voorkomt passief afluisteren op de lijn.

Protocollaag (Hashiverse-cryptografie): TLS alleen is niet voldoende voor een trustless gedecentraliseerd netwerk — een gecompromitteerde of kwaadwillende server zou nog steeds gemanipuleerde inhoud kunnen aanbieden over een geldige TLS-verbinding. De eigen cryptografie van Hashiverse biedt de diepere garantie: elk stuk inhoud wordt ondertekend door de sleutels van zijn auteur, berichten worden in rust versleuteld met sleutels die de server nooit bezit, en server-identiteiten zijn gebonden aan proof-of-work-verbintenissen. Een client hoeft geen enkele server te vertrouwen; hij verifieert inhoud rechtstreeks tegen cryptografische handtekeningen, ongeacht hoe deze is aangekomen.

TLS regelt het netwerk; Hashiverse-cryptografie regelt de waarheid.