Vom "Digitalen Radiergummi" zur funktionalen Privacy-Anwendung

Die Sicherheitsarchitektur von melting Link folgt dem Prinzip des Zero-Knowledge. Der Server dient ausschließlich als "Blind Storage". Er speichert BLOBs, deren Inhalt er mathematisch nicht lesen kann, und indexiert diese über Hashes, deren Urbild (Pre-Image) er nicht kennt.

1. Key Derivation & Domain Separation

Ein zentrales Sicherheitsmerkmal ist die Trennung von "Locator" (wo liegt der Thread?) und "Decryption Key" (wie lese ich ihn?). Beide werden aus demselben Geheimnis (dem URL-Fragment) abgeleitet, aber mittels PBKDF2-HMAC-SHA256 (100.000 Iterationen) und unterschiedlichen, fest codierten Salts ("Domain Separation"). Das war bei der Version von 2012 auch schon so, nur dass es damals noch Keystretching hieß und mit sha1 oder md5 iterierte. Es lief nur auf dem Server und man musste darauf vertrauen, dass er die Schlüssel wegwirft. Hat er, aber es war nicht beweisbar. Hier kann jeder F12 drücken und in der Konsole sehen, was den Browser verlässt.

Selbst wenn der Server alle Anfragen mitloggt (was er nicht tut), sieht er nur die Public ID. Er kann daraus unmöglich auf den Content Key zurückrechnen, da er das ursprüngliche Secret nicht kennt. Die Links (der Teil der hinter dem # in der URL steht), und damit das Secret, sind frei wählbar. Für sensible Daten sollte man daher keine erratbaren Namen wie 'Bankdaten' oder 'Geheimnis' wählen, da diese durch einfaches Ausprobieren gefunden werden könnten (Rainbow-Table-Attacken auf den Link-Namen). Empfehlung: Lassen Sie das Feld leer, um eine kryptografisch sichere Zufallsfolge generieren zu lassen, oder geben Sie selbst eine lange, komplexe Zeichenfolge ein

2. Symmetrische Verschlüsselung

Alle Inhalte (Texte, Bilder) werden lokal im Browser verschlüsselt.

• Algorithmus: AES-256-GCM (Galois/Counter Mode).
• Eigenschaften: Authenticated Encryption with Associated Data (AEAD). Das GCM-Verfahren garantiert nicht nur Vertraulichkeit, sondern auch Integrität. Der Ciphertext kann nicht unbemerkt manipuliert werden.
• IV: 12 Byte Random IV, generiert via window.crypto.getRandomValues().

3. Asymmetrische Kryptografie & Moderation

Jeder Thread besitzt ein temporäres ECDSA Keypair (NIST P-256 Kurve).

• Der Public Key wird beim Erstellen auf dem Server gespeichert.
• Der Private Key wird Teil des Admin-Links und verlässt niemals den Browser.
• Löschbefehle (DELETE) müssen clientseitig signiert werden: Sign(cmd:target:timestamp). Der Server prüft die Signatur gegen den gespeicherten Public Key. Ohne den Admin-Link kann der Eintrag also nicht manipuliert werden. Was bleibt, ist der Ablaufzeitpunkt. Jeder Eintrag hat eine Anzeige, wann der Inhalt gelöscht wird. DDieser Zeitpunkt wird beim Erstellen definiert und ist danach unveränderlich.

4. Chiffre-Modus (Hybrid ECIES) (geplant)

Im "Chiffre"-Modus (Public Key Encryption) nutzen wir ein hybrides Verfahren, ähnlich wie moderne Messenger. Da WebCrypto keine direkte ECIES-Unterstützung bietet, implementieren wir dies manuell:

• Wir nutzen den Admin-Public-Key als Empfänger-Adresse.
• Der Sender (Gast) generiert ein Ephemeral Keypair (ECDH).
• Via ECDH (Elliptic Curve Diffie-Hellman) wird ein Shared Secret vereinbart.
• Aus diesem Secret wird ein symmetrischer AES-Key abgeleitet, der die Nachricht verschlüsselt.
• Resultat: Nur der Inhaber des Admin-Links kann die Nachrichten entschlüsseln. Dies macht den Unterschied zum normalen Chat-Forum aus und bietet damit die Funktion eines sicheren Briefkastens für den Ersteller.