Zero-Knowledge-Architektur
Der Server speichert ausschließlich Chiffrat – er besitzt keinen Schlüssel, kein Passwort und keinen lesbaren Inhalt. Architektonisch erzwungen, nicht nur versprochen.
Vertrauensmodell
Die Sicherheitsgrenze ist kein Versprechen, sondern eine Konsequenz der Architektur. Der Server empfängt niemals die Eingaben, die zur Entschlüsselung deiner Daten erforderlich wären.
auth_token (HKDF-Credential)Kerngarantien
Dein Passwort durchläuft lokal Argon2id, um einen Master-Schlüssel zu erzeugen. Der Server empfängt nur ein per HKDF abgeleitetes auth_token – ein Credential, das mathematisch vom Passwort und von den Verschlüsselungsschlüsseln getrennt ist. Selbst wenn dieses Token gestohlen würde, kann damit kein Tresorinhalt entschlüsselt werden.
Deine X25519- und ML-KEM-768-Private-Keys werden im Browser generiert und sofort mit AES-256-GCM(master_key, …) umschlossen, bevor sie hochgeladen werden. Der Server speichert das Chiffrat. Ohne deinen Master-Schlüssel – der dein Gerät niemals verlässt – sind die Blobs bedeutungslos.
Jeder Speichervorgang erzeugt einen frischen Data-Encryption-Key (DEK). Der DEK verschlüsselt deine Mindmap mit AES-256-GCM und wird dann selbst mit einem hybriden klassischen + Post-Quanten-KEM umschlossen. Der Server speichert den umschlossenen DEK und den Blob – hat aber keine Möglichkeit, den DEK zu entschlüsseln. Kein Schlüssel-Reuse zwischen Speichervorgängen.
So funktioniert es
Der Server hasht auth_token nochmals mit Argon2id, bevor er ihn speichert – das Credential in der Datenbank ist also ein abgeleiteter Hash, nicht das originale Token.
Der DEK wird nirgendwo gespeichert. Er wird auf Anfrage vom Client mithilfe seiner Private Keys neu abgeleitet. Jeder Speichervorgang ist unabhängig verschlüsselt – kein Schlüssel-Reuse zwischen Speichervorgängen oder zwischen Nutzern.
Kryptografie-Stack
Verschlüsselt alle Inhalte: Mindmap-Blobs, Map-Titel und Private-Key-Blobs. Verwendet die native Web-Crypto-API des Browsers – keine externe Krypto-Bibliothek für die symmetrische Verschlüsselung.
Leitet den Master-Schlüssel aus deinem Passwort ab. Parameter: 64 MiB Arbeitsspeicher, 3 Iterationen, 4 Threads. Implementiert via hash-wasm (WebAssembly) – läuft vollständig im Browser.
Elliptische-Kurven-Diffie-Hellman für die klassische Hälfte des Hybrid-KEM. Erzeugt bei jedem Speichervorgang ein ephemeres Schlüsselpaar – kein Langzeit-Schlüssel-Reuse. Implementiert via @noble/curves.
Die Post-Quanten-Hälfte des Hybrid-KEM. Von NIST 2024 standardisiert (FIPS 203). Schützt vor zukünftigen Quantencomputern, die X25519 mit dem Shor-Algorithmus brechen könnten. Via @noble/post-quantum.
Leitet domänengetrennte Schlüssel aus dem Master-Schlüssel ab ("crypt-mind-auth-v1", "crypt-mind-title-v1", "crypt-mind-dek-v1") und kombiniert die klassischen und Post-Quanten-Shared-Secrets. Via @noble/hashes.
Kombiniert X25519- und ML-KEM-768-Shared-Secrets via HKDF: HKDF(klassisch ‖ pq). Die Sicherheit gilt, solange eine der beiden Schichten ungebrochen bleibt – ein konservatives Defense-in-Depth-Design.
Datenübersicht
Argon2id(auth_token) – Credential-HashAES-256-GCM(master_key, x25519_private)AES-256-GCM(master_key, mlkem_private)AES-256-GCM(DEK, map_content) – MinIOAES-256-GCM(title_key, map_title)Wenn die gesamte Datenbank und der Objektspeicher gestohlen würden, sähe ein Angreifer ausschließlich opake Chiffrat-Blobs und öffentliche Schlüssel. Ohne dein Passwort ist es rechnerisch nicht möglich, den Inhalt wiederherzustellen.
Bedrohungsmodell
auth_token allein kann keinen Tresorinhalt entschlüsseln.Das Security-Whitepaper deckt jeden Ablauf im Detail ab: vollständige Schlüsselableitungsbäume, komplettes Bedrohungsmodell, Session-Sicherheit und Technologie-Stack.