Burn-After-Reading · Selbstzerstörende Nachrichten

Burn-After-Reading QR-Codes

Einmalige, selbstzerstörende Nachrichten mit Ende-zu-Ende-Verschlüsselung. Der Server speichert nur den Ciphertext — nie das Passwort, nie den Klartext.

Burn-After-Reading QR erstellen

1. Was ist Burn-After-Reading?

«Burn after reading» — verbrenne nach dem Lesen — ist ein Prinzip aus der Spionage-Kommunikation: Eine Nachricht existiert nur so lange, bis sie einmal gelesen wurde, dann wird sie vernichtet. Digitale Burn-After-Reading-Systeme übertragen dieses Prinzip auf verschlüsselte Online-Nachrichten.

Das QR-Secure Burn-After-Reading-Feature speichert den verschlüsselten Inhalt (Ciphertext) temporär auf dem Server. Sobald der Empfänger den QR-Code scannt und die Nachricht abruft, wird der Ciphertext unwiderruflich aus der Datenbank gelöscht. Auch nach Ablauf einer konfigurierbaren Lebensdauer (1 Stunde bis 30 Tage) wird alles automatisch entfernt.

Das Passwort und der Klartext verlassen zu keinem Zeitpunkt deinen Browser. Die Verschlüsselung ist clientseitig mit AES-256-GCM identisch zum Standard-Modus — der einzige Unterschied ist, wo der Ciphertext zwischengespeichert wird.

2. Unterschied zum normalen QR-Secure-Modus

Der Standard-Modus (ISQR1) ist vollständig selbstenthalten: Der Ciphertext steckt direkt im QR-Code, kein Server wird benötigt. Burn-After-Reading ist ein bewusst anderer Ansatz mit anderen Garantien und Kompromissen.

Eigenschaft Standard-Modus (ISQR1) Burn-After-Reading
Ciphertext auf Server Nein — steckt im QR Ja, temporär
Zero-Knowledge Strikt Verschlüsselt, Server sieht Ciphertext
Funktioniert offline Ja Nein
Echte Self-Destruct Garantie Nein Ja
QR-Grösse wächst mit Inhalt Ja (längerer Inhalt = grösserer QR) Nein, immer gleich klein
Abruf-Limit erzwingbar Nein Ja (1–10 Abrufe)
Lebensdauer-Limit Nein (dauerhaft im QR) Ja (1h bis 30 Tage)
Serverabhängigkeit Keine istyle.ch-Server
Empfohlen für Persistente Inhalte, Ausdrucken, Offline Einmalige, sensible, zeitkritische Nachrichten

3. Technische Architektur

Die Verschlüsselung läuft vollständig clientseitig. Der Server sieht zu keinem Zeitpunkt das Passwort oder den Klartext — nur den Ciphertext-Blob.

Absender-Browser istyle.ch Server Empfänger-Browser 1. Text + Passwort eingeben 2. AES-GCM verschlüsseln (lokal) POST /api/burn/create {ciphertext, salt, iv, max_uses, expires_at} 3. Generiert ID (22 Zeichen) 4. Speichert Ciphertext in DB Response: {id, url, delete_token} 5. QR mit Burn-URL erstellen — Empfänger scannt QR — GET /b/{id} 6. Prüft ID, Ablauf, Abrufe HTML: Passwort-Dialog POST /api/burn/reveal/{id} 7. SELECT FOR UPDATE → DELETE {ciphertext, salt, iv, was_destroyed} 8. Entschlüsseln im Browser
Vollständiger Ablauf von der Verschlüsselung bis zur Selbstzerstörung.

Eingesetzte Technologien

  • Verschlüsselung: AES-256-GCM mit PBKDF2-SHA-256 (250 000 Iterationen, 16 Byte Salt, 12 Byte IV) — identisch zum Standard-Modus ISQR1.
  • ID-Generierung: 22 Zeichen aus dem nanoid-Alphabet (A–Z, a–z, 0–9, _-) → ~131 Bit Entropie. Kollisionswahrscheinlichkeit praktisch null.
  • Race-Condition-Schutz: MySQL InnoDB SELECT … FOR UPDATE in einer Transaktion stellt sicher, dass bei gleichzeitigen Requests genau einer den Ciphertext erhält.
  • Garbage Collection: Cron-Script alle 15 Minuten löscht abgelaufene und vollständig verbrauchte Einträge physisch.
  • Rate-Limiting: MySQL-basierte Sliding-Window-Buckets pro IP und Endpoint.
  • delete_token: 32-Byte Zufallstoken, SHA-256-Hash gespeichert. Im LocalStorage des Ersteller-Browsers.

4. Wann sollte ich welchen Modus verwenden?

Standard-Modus (ISQR1) ist besser, wenn…

  • …der QR-Code ausgedruckt oder in ein Dokument eingebettet werden soll.
  • …du keine Abhängigkeit von einem Server haben möchtest (Offline-Nutzung).
  • …der Inhalt mehrfach von verschiedenen Personen abgerufen werden soll.
  • …du maximale Kontrolle über die Lebensdauer haben möchtest (QR existiert solange du ihn aufbewahrst).
  • …du strikt Zero-Knowledge bleiben willst — kein Server, keine Datenbank, kein Netzwerk.

Burn-After-Reading ist besser, wenn…

  • …du sicher sein willst, dass die Information nur einmal abgerufen werden kann.
  • …du eine zeitliche Begrenzung erzwingen willst (z. B. «nur heute gültig»).
  • …du eine einmalige Zugangsinformation teilen willst: temporäres Passwort, Einmal-PIN, geheimes Dokument.
  • …du wissen willst, ob die Nachricht bereits abgerufen wurde (Fehlen der Nachricht = wurde gelesen).
  • …der Inhalt zu lang für einen kompakten QR-Code wäre (Burn-URL ist immer kurz).

5. Sicherheitsversprechen und Grenzen

Was wir garantieren

  • Der Klartext kommt nie auf unsere Server — Verschlüsselung ist ausschliesslich clientseitig.
  • Das Passwort wird nie übertragen — weder im Klartext noch verschlüsselt.
  • Der Ciphertext wird nach Abruf (oder Ablauf) physisch aus der DB gelöscht, nicht nur als «gelöscht» markiert.
  • Bei gleichzeitigen Abrufversuchen erhält genau einer den Ciphertext (Race-Condition-sicher via InnoDB-Transaktionen).
  • Keine IP-Adressen, User-Agents oder andere Metadaten in der Burn-Datenbank.

Bekannte Grenzen

  • Kein Nachweis der Löschung: Wir geben was_destroyed: true zurück, aber du musst uns beim Wort nehmen. Anders als beim Standard-Modus ist keine rein mathematische Garantie möglich.
  • Server-Kompromittierung: Wenn unser Server kompromittiert würde, bevor der Ciphertext gelöscht wird, könnte ein Angreifer ihn auslesen. Ohne dein Passwort bleibt er trotzdem unlesbar.
  • Timing: Zwischen Erstellung und Abruf existiert der Ciphertext auf dem Server. Je kürzer die gewählte Lebensdauer, desto kleiner dieses Zeitfenster.
  • Rechtliche Auskunftspflicht: Wenn ein Gericht Daten anfordert, könnten noch nicht abgelaufene Ciphertexte herausgegeben werden — nicht entschlüsselt, da wir das Passwort nie hatten.

6. Was passiert, wenn die Nachricht vor mir abgerufen wurde?

Wenn du eine Burn-After-Reading-URL öffnest und die Meldung «Nachricht nicht verfügbar» erhältst, bedeutet das: Die Nachricht existiert nicht mehr. Das kann verschiedene Gründe haben:

  • Jemand hat die Nachricht vor dir abgerufen — möglicherweise hat der QR-Code jemanden erreicht, den er nicht sollte.
  • Die Lebensdauer ist abgelaufen.
  • Der Ersteller hat die Nachricht manuell gelöscht.
  • Der Link ist fehlerhaft.

In diesem Fall solltest du den Absender kontaktieren und klären, ob die Nachricht noch einmal versendet werden soll. Verwende das Passwort nicht weiter, falls du befürchtest, dass jemand die Nachricht abgefangen hat.

7. Kann istyle.ch meine Nachricht lesen?

Nein. Der Klartext und das Passwort verlassen zu keinem Zeitpunkt deinen Browser. Wir speichern nur den AES-256-GCM-Ciphertext — das ist mathematisch ohne das Passwort nicht entschlüsselbar. Unser System hat keinen Zugriff auf dein Passwort.

Was der Server sieht:

  • Einen Base64url-codierten Ciphertext-Blob (unlesbar ohne Passwort)
  • Salt und IV (beide öffentlich, haben ohne Passwort keinen Wert)
  • Zeitstempel und Konfiguration (max_uses, expires_at)
  • Den SHA-256-Hash des Lösch-Tokens

Was der Server nie sieht: Dein Passwort, den Klartext, einen Schlüssel.

8. Warum ist das keine «echte Zero-Knowledge»-Architektur mehr?

Zero-Knowledge bedeutet im strengen Sinn: Der Server erfährt nichts — nicht einmal den Ciphertext. Das ist beim Standard-Modus ISQR1 der Fall, weil der gesamte Ciphertext im QR-Code steckt und unser Server nie kontaktiert wird.

Beim Burn-After-Reading-Modus muss der Server den Ciphertext zwischenhalten — anders kann er ihn später an den Empfänger liefern und danach löschen. Das ist die unvermeidliche Konsequenz der Self-Destruct-Architektur.

Die Verschlüsselung ist trotzdem clientseitig und end-to-end: Das Passwort reist nie zum Server, und der Ciphertext ist ohne Passwort wertlos. Aber der Server ist am Prozess beteiligt — das ist der Unterschied zwischen «Zero-Knowledge» und «End-to-End-verschlüsselt».

Wir kommunizieren diesen Unterschied transparent auf jeder Burn-After-Reading-Seite und empfehlen den Standard-Modus, wenn strikte Zero-Knowledge-Garantien wichtig sind.

9. FAQ — Häufige Fragen

Was ist Burn-After-Reading?

«Burn after reading» ist eine verschlüsselte Nachricht, die sich nach dem ersten Abruf selbst zerstört. Der Empfänger kann sie genau einmal lesen — danach ist sie permanent gelöscht.

Kann istyle.ch meine Nachricht lesen?

Nein. Der Klartext und das Passwort verlassen deinen Browser nie. Der Server speichert nur den AES-256-GCM-Ciphertext, der ohne das Passwort unlesbar ist.

Was passiert, wenn jemand die Nachricht vor mir abruft?

Du siehst die Meldung «Nachricht nicht verfügbar». Das bedeutet: Der Ciphertext ist weg. Kontaktiere den Absender und kläre, ob die Nachricht erneut versendet werden soll.

Warum ist Burn-After-Reading keine echte Zero-Knowledge-Architektur?

Weil der Server den Ciphertext vorübergehend speichern muss. Beim Standard-Modus verlässt der Ciphertext nie den Browser — er steckt im QR. Bei Burn muss der Server ihn halten, bis er abgerufen und gelöscht wird.

Was passiert nach Ablauf der Lebensdauer?

Ein automatisches Cron-Script löscht alle abgelaufenen Einträge alle 15 Minuten physisch aus der Datenbank. Nach Ablauf ist der Ciphertext unwiderruflich weg.

Was passiert bei mehreren gleichzeitigen Abrufversuchen?

Dank MySQL InnoDB Row-Locking (SELECT FOR UPDATE) erhält genau ein Client den Ciphertext. Alle anderen bekommen «Gone». Race-Conditions sind ausgeschlossen.

Kann ich eine Burn-Nachricht nachträglich löschen?

Ja. Nach der Erstellung wird ein Lösch-Token im Browser-LocalStorage gespeichert. Mit diesem Token kann die Nachricht manuell per API gelöscht werden.

Wie gross darf der Inhalt sein?

Maximal 100 KB Klartext. Das entspricht ca. 137 KB Base64url-codiertem Ciphertext. Das deckt die Mehrzahl der Anwendungsfälle ab.

Was bedeutet Selbstzerstörung bei falschem Passwort?

Nach einer konfigurierbaren Anzahl fehlgeschlagener Entschlüsselungsversuche (Standard: 5) wird der Ciphertext automatisch gelöscht. Schutz gegen Brute-Force.

Werden meine IP-Adresse oder andere Metadaten gespeichert?

Nein. In der Burn-Datenbank stehen keine IP-Adressen, User-Agents, E-Mail-Adressen oder Geolokation.

Funktioniert Burn-After-Reading ohne Internetverbindung?

Nein. Der Empfänger braucht eine Verbindung zum istyle.ch-Server, um den Ciphertext abzurufen. Für Offline-Szenarien nutze den Standard-Modus.

Wann sollte ich Burn-After-Reading wählen?

Wenn du sicherstellen willst, dass die Information nur einmal gelesen werden kann — z. B. für temporäre Passwörter, Einmal-PINs, sensible einmalige Dokumente oder zeitkritische Informationen.