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.

Es gibt vier Betriebsarten, die sich nur darin unterscheiden, wer schreiben und wer lesen darf:

• Chat: Jeder mit dem Link kann lesen und antworten.
• Einmalnachricht: Wird nach dem ersten Öffnen sofort vom Server gelöscht.
• Postfach: Jeder kann etwas einwerfen, lesen kann nur der Ersteller.
• Notiz: Eine Nachricht ohne Antwortmöglichkeit.

1. Key Derivation & Domain Separation

Ein zentrales Sicherheitsmerkmal ist die Trennung von "Locator" (wo liegt der Thread?) und "Content Key" (wie lese ich ihn?). Beide entstehen aus demselben Geheimnis, aber auf getrennten Zweigen: Zunächst wird das Secret per PBKDF2-HMAC-SHA256 mit 600.000 Iterationen auf einen 256-Bit-Masterschlüssel gedehnt. Aus diesem Master leitet anschließend HKDF-SHA256 die einzelnen Schlüssel ab — jeder Zweig mit einem eigenen, festen Domain-Label ("Domain Separation"). Aus einem Zweig lässt sich kein anderer zurückrechnen.

Ist ein Kennwort vergeben, greift ein zweiter, unabhängiger Pfad: Als Eingangsmaterial dient dann Name::Passwort, und in den PBKDF2-Salt fließt zusätzlich ein thread-spezifischer auth_salt ein. Der Inhalt ist damit ohne Kennwort nicht nur serverseitig gesperrt, sondern kryptografisch unzugänglich — auch für den Betreiber. Parallel entsteht auf einem eigenen HKDF-Zweig ein Auth Token, den der Server ausschließlich als SHA-256-Hash speichert; er dient nur als Nachweis für Benachrichtigungen und verrät nichts über den Content Key.

Die Salts selbst sind nicht fest im Code hinterlegt, sondern werden beim Start aus einem Instance-Pepper der jeweiligen Installation abgeleitet (HMAC-SHA256(Pepper, Label)). Nur die Labels sind feste Domain-Trenner. Damit sind identische Namen auf zwei verschiedenen Installationen kryptografisch völlig verschieden — Links sind an ihr Deployment gebunden, und vorberechnete Tabellen müssten für jede Instanz einzeln erstellt werden.

Selbst wenn der Server jede Anfrage protokolliert (ein Audit-Log ist optional zuschaltbar), sieht er nur die Public ID — und selbst die nicht im Klartext: In der Datenbank steht lediglich deren Hash. Auf den Content Key kann er unmöglich zurückrechnen, da er das ursprüngliche Secret nie erhält. Das Geheimnis ist der Teil der URL hinter dem #, den Browser grundsätzlich nicht an Server senden.

Der Name ist frei wählbar, und genau hier liegt die Verantwortung beim Nutzer: Erratbare Namen wie "Bankdaten" oder "Geheimnis" lassen sich durch Ausprobieren finden. Standardmäßig wird deshalb ein 14-stelliges Zufallspräfix (≈ 84 Bit Entropie) vorangestellt, das jeden Namen unerratbar macht. Wer das Präfix abschaltet, sollte eine lange, komplexe Zeichenfolge wählen — oder das Feld leer lassen und den Namen vollständig zufällig erzeugen lassen.

Das Prinzip ist übrigens nicht neu: Schon die Version von 2012 arbeitete so, nur hieß es damals Keystretching und iterierte über SHA-1 oder MD5. Der entscheidende Unterschied: Es lief auf dem Server, und man musste darauf vertrauen, dass er die Schlüssel wegwirft. Er hat es getan — beweisen ließ es sich nicht. Heute kann jeder F12 drücken und in der Konsole sehen, was den Browser verlässt.

2. Symmetrische Verschlüsselung

Alle Inhalte (Texte, Bilder, Office-Dokumente) 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().
• Kompression: Inhalte werden vor der Verschlüsselung komprimiert. Das spart Platz und lässt den Datenblock nach außen noch strukturloser wirken.
• Anhänge: Größere Dateien liegen als eigene, separat verschlüsselte Blöcke auf dem Server – ebenfalls unlesbar für ihn.

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 zeigt an, wann er gelöscht wird. Festgelegt wird das beim Erstellen. Ändern kann ihn danach nur, wer den Admin-Link besitzt – und auch der nur innerhalb der Grenzen, die der Betreiber gesetzt hat.

4. Postfach-Modus (geplant: Hybrid ECIES)

Das Postfach soll ein digitaler Briefkasten sein: Jeder darf einwerfen, aber nur der Ersteller darf lesen. Heute setzt der Server das durch – er liefert die Einwürfe ausschließlich an den Inhaber des Admin-Links aus. Für den Server selbst sind sie auch jetzt schon unlesbar, denn der Schlüssel steckt im Link, den er nie zu sehen bekommt. Was noch fehlt, ist der Schutz der Einwerfer untereinander. Genau das soll die nächste Ausbaustufe leisten – mit demselben Verfahren, das moderne Messenger nutzen:

• Beim Erstellen entsteht zusätzlich ein zweites Schlüsselpaar allein für dieses Postfach. Der öffentliche Teil liegt für alle sichtbar beim Thread, der geheime Teil steckt im Admin-Link.
• Wer etwas einwirft, erzeugt im eigenen Browser ein Einwegschlüsselpaar und einigt sich damit rechnerisch mit dem öffentlichen Schlüssel des Erstellers auf ein gemeinsames Geheimnis (ECDH).
• Aus diesem Geheimnis entsteht der AES-256-Schlüssel für genau diesen einen Beitrag. Er wird nirgends gespeichert und ist für jeden Einwurf ein anderer.
• Ergebnis: Nur der Inhaber des Admin-Links kann die Einwürfe lesen – dann nicht mehr, weil der Server es so einrichtet, sondern weil die Mathematik es so vorgibt.

5. Das Wallet: Links merken ohne Konto

Wer mehrere Links nutzt, will sie nicht alle von Hand aufbewahren. Dafür gibt es das Wallet – eine Merkliste, die es 2012 noch nicht gab. Sie kommt ohne Konto aus, denn sie liegt nicht bei uns, sondern in deinem Browser.

• Die Liste wird verschlüsselt im Browser abgelegt. Der zugehörige Schlüssel liegt getrennt davon in einem Bereich, aus dem der Browser ihn nicht herausgibt – auslesen lässt er sich nicht, benutzen nur auf dieser Seite.
• Optional lässt sich die Liste zusätzlich auf dem Server sichern, um sie auf mehreren Geräten zu haben. Dafür vergibst du ein eigenes Passwort; verschlüsselt wird auch hier vorher im Browser. Der Server bekommt wieder nur einen Datenblock, mit dem er nichts anfangen kann.
• Das Wallet meldet außerdem, wenn in einem gespeicherten Thread etwas Neues liegt. Bei passwortgeschützten Threads geht das nur, wenn du das Passwort einmal korrekt eingegeben hast – ohne diesen Nachweis verrät der Server nicht einmal, dass es Neues gibt.
• Wichtig: Das Wallet enthält die Links selbst – und ein Link ist der Schlüssel. Auf einem fremden oder unsicheren Gerät sollte man es deshalb nicht anlegen.

6. Was wir nicht versprechen

Einen perfekten digitalen Radiergummi gibt es nicht – das war 2011 so und ist es heute. Was Technik leisten kann, endet an diesen Stellen:

• Wer etwas lesen darf, kann es abschreiben, abfotografieren oder weiterleiten. Dagegen hilft keine Verschlüsselung, sondern nur die Auswahl der Empfänger.
• Der Link ist der Schlüssel. Wer ihn hat, kommt hinein – also gehört er in einen sicheren Kanal und nicht in eine offene Chatgruppe.
• Der Server sieht die Inhalte nie, aber er sieht den Verkehr: dass ein Eintrag existiert, wann er abgerufen wird und wie groß er ungefähr ist. Diese Randdaten halten wir so knapp wie möglich, verschwinden lassen sie sich nicht.
• Und wie bei jeder Web-Anwendung gilt: Der Code, der die Verschlüsselung ausführt, kommt vom Server. Wir zeigen offen, was er tut – prüfbar bleibt es nur, weil er im Browser läuft und dort jederzeit einsehbar ist.