Kryptografische Grundlage

Jedes Versprechen, das Hashiverse zu Datensouveränität, Zensur­resistenz und Eigentums­unabhängigkeit gibt, ist durch Kryptografie gedeckt. Das ist keine Fassade — das ist der Grund, warum diese Versprechen halten. Die kryptografische Schicht zu verstehen heißt, das Fundament zu verstehen, auf dem alles andere ruht.

Identität

Eine Hashiverse-Identität wird nicht von einem Server zugeteilt. Sie wird aus Schlüsseln abgeleitet: 

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

Deine öffentliche ID ist ein 256-Bit-Hash aus drei öffentlichen Schlüsseln — einem klassischen (Ed25519), zwei post-quantischen (FN-DSA/Falcon und ML-DSA/Dilithium). Die 16-Byte-Commitments zu den PQ-Schlüsseln binden sie schon jetzt in deine Identität, bevor Quantencomputer eine praktische Bedrohung sind. Wenn die Quantenmigration stattfindet, ist der Upgrade-Pfad bereits in jeder Identität im Netzwerk eingebettet.

Server-Identitäten funktionieren genauso, mit der zusätzlichen Anforderung, dass die ID eine Proof-of-Work-Bedingung erfüllen muss (führender Null-Präfix im Hash). Das macht die Erstellung einer Server-Identität rechen­intensiv und verhindert Sybil-Angriffe auf den DHT-Ring.

Der private Ed25519-Signierschlüssel des Clients wird ausschließlich in der sicheren Enklave der Web Crypto API des Browsers als nicht extrahierbares CryptoKey-Objekt gehalten. Der Browser stellt nur eine Signier­operation bereit — die Roh-Bytes des privaten Schlüssels sind weder für JavaScript noch für das WASM-Modul oder anderen Code auf der Seite zugänglich. Es gibt keinen Mechanismus, den privaten Schlüssel nach dem Import zu exportieren oder abzurufen. Das Signieren geschieht innerhalb der kryptografischen Schicht des Browsers; der Schlüssel verlässt sie nie.

Das ist eine bewusste Beschränkung, keine Einschränkung. Selbst wenn der WASM-Client von Hashiverse vollständig kompromittiert wäre, könnte ein Angreifer höchstens die Signier­operation im Namen des Opfers aufrufen — er könnte den Schlüssel nicht stehlen und anderswo verwenden.

Quelle: hashiverse-lib/src/tools/ — Typen Hash, Id, Signature; server_id.rs für die Proof-of-Work der Server-Identität.

Hybride Post-Quanten-Signaturen

Die Drei-Schlüssel-Identität ermöglicht einen progressiven Migrationspfad:

SPHINCS+ wurde erwogen und verworfen: Seine Signaturen sind mehrere Kilobyte groß, was für ein Beitrags­netzwerk mit hohem Durchsatz prohibitiv ist. Die Falcon+ Dilithium-Kombination liefert zwei unabhängige gitterbasierte Sicherheits­annahmen, sodass beide gleichzeitig gebrochen werden müssten, damit die Identität kompromittiert wird.

Quelle: hashiverse-lib/src/tools/ kryptografische Primitiven; encoded_post.rs für die Auswahl des Signaturmechanismus pro Beitrag.

Hashing

Blake3 ist die primäre Hashfunktion — schnell, parallelisierbar und geeignet für Prüfsummen, inhaltsadressierung und Schlüsselableitung. Für Proof-of-Work umfasst die im Protokoll verfügbare Hash-Suite Blake2, Blake3, SHA2, SHA3, Whirlpool, Groestl und Skein. Proof-of-Work verkettet mehrere Algorithmen in einer pseudozufälligen Sequenz, was die ASIC-Resistenz erhöht, weil eine effiziente Co-Implementierung mehrerer pfadabhängiger Algorithmen gleichzeitig erforderlich ist.

Alle Hash-Bibliotheken werden auch in Debug-Builds mit opt-level=3 kompiliert — das ist in den Profil-Überschreibungen der Workspace-Cargo.toml konfiguriert, damit Test-Suiten nicht durch Hash-Berechnung gebremst werden.

Verschlüsselung im Ruhezustand

Auf Servern gespeicherte Beiträge werden mit ChaCha20-Poly1305 verschlüsselt. Der Schlüssel wird aus einer Passphrase abgeleitet, die vom Bucket-Typ abhängt:

Ein eigenes Multi-Passphrase-Verschlüsselungs­schema, lose inspiriert von age, bedeutet, dass ein einziger Beitrag, der mehrere Kontexte abdeckt — ein Hashtag-Beitrag, der auch einen Nutzer erwähnt — mit einer beliebigen der Passphrasen entschlüsselt werden kann. Server speichern verschlüsselte Bytes, die sie nicht lesen können. Es gibt keinen Klartext auf der Server-Festplatte.

Quelle: encoded_post.rs für die Beitrags­verschlüsselung; hashiverse-lib/src/tools/ für die ChaCha20-Poly1305-Primitiven.

Signaturen auf allem

Jeder Beitrag wird von seinem Autor signiert. Jede Server­antwort wird vom liefernden Server signiert. Jedes Bundle wird signiert. Signaturen sind keine optionalen Metadaten — sie sind der Mechanismus, mit dem Clients Inhalten von nicht vertrauens­würdigen Servern vertrauen können. Ein Client muss niemals einem Server vertrauen; er vertraut der kryptografischen Signatur auf den Inhalten, die der Server liefert.

Zwei Schichten Transport-Sicherheit

Hashiverse trennt Transport-Verschlüsselung von Protokoll-Sicherheit und behandelt sie als unabhängige Anliegen:

Transportschicht (TLS): Server-zu-Server- und Client-zu-Server-Kommunikation läuft über HTTPS mit TLS-Zertifikaten von Let's Encrypt. Da Hashiverse-Server eher per IP-Adresse als per Domainname identifiziert werden, bezieht der Server ein reines IP-TLS-Zertifikat über das ACME-Protokoll. Das verschlüsselt den Datenverkehr im Transit und verhindert passives Mithören auf der Leitung.

Protokollschicht (Hashiverse-Kryptografie): TLS allein reicht für ein vertrauensloses, dezentrales Netzwerk nicht — ein kompromittierter oder bösartiger Server könnte über eine gültige TLS-Verbindung dennoch manipulierte Inhalte ausliefern. Hashiverses eigene Kryptografie liefert die tiefere Garantie: Jeder Inhalt wird mit den Schlüsseln seines Autors signiert, Beiträge werden im Ruhezustand mit Schlüsseln verschlüsselt, die der Server nie hält, und Server-Identitäten sind an Proof-of-Work-Commitments gebunden. Ein Client muss keinem Server vertrauen; er prüft Inhalte direkt gegen kryptografische Signaturen, unabhängig davon, wie sie ankamen.

TLS kümmert sich ums Netzwerk; die Hashiverse-Kryptografie kümmert sich um die Wahrheit.