Verschlüsselung
Wie Collogue eine private Nachricht verschlüsselt
Eine kompakte Erklärung des überprüften browserbasierten Verschlüsselungsablaufs von Collogue.
Veröffentlicht: 17. Februar 2026
Grenzen der aktuellen Implementierung
Aktuelle Collogue-Links enthalten die verschlüsselte Nutzlast in der URL. Der Browser verwendet die Web Crypto API: PBKDF2-SHA-256 mit 310.000 Iterationen leitet aus dem separat eingegebenen Passwort einen 256-Bit-AES-GCM-Schlüssel ab, mit einem zufälligen 16-Byte-Salt und einem 12-Byte-IV. Der aktuelle Client sendet keine Anwendungs-API-Anfrage zum Erstellen, Abrufen oder Speichern von Nachrichten.
Das Passwort ist nicht im Link kodiert. Die Implementierung bietet keine einmalige Ansicht, keine serverseitige Löschung und keinen Ablauf-Timer. Behandeln Sie den vollständigen Link als sensibel und teilen Sie das Passwort über einen separaten Kanal.
Weiterer Kontext
Die Idee ist einfach. Die korrekte Umsetzung bringt die interessanten Probleme mit sich.
Eine Nachricht beginnt als lesbarer Text im Browser des Absenders.
- der Benutzer;
- der Browser;
- Skripte der Seite;
- Browser-Erweiterungen mit ausreichendem Zugriff;
- Schadsoftware auf dem Gerät;
- Systeme für Barrierefreiheit und Eingaben.
Das ist kein ausschließliches Problem von Collogue. Ein Geheimnis muss irgendwo in lesbarer Form existieren, bevor es verschlüsselt werden kann.
Ein kryptografischer Schlüssel sollte aus einer kryptografisch sicheren Quelle oder einem dokumentierten Ableitungsverfahren stammen. Menschlich aussehende Zufälligkeit reicht nicht. Ein Zeitstempel mit dekorativer Zeichensetzung bleibt ein Zeitstempel.
Wenn eine Passphrase beteiligt ist, muss die Implementierung eine geeignete Schlüsselableitungsfunktion mit geeigneten Parametern verwenden. Wird ein zufälliger Schlüssel erzeugt, sollten seine Länge und die Quelle der Erzeugung dokumentiert werden.
- Vertraulichkeit — Der Chiffretext verrät ohne den Schlüssel nichts über den Klartext.
- Integrität — Unbefugte Änderungen werden bei der Entschlüsselung erkannt.
Die öffentliche Seite sollte die genaue Konstruktion erst nach einer Überprüfung des Codes nennen. „AES“ allein ist keine vollständige Beschreibung. Modi, Nonces, Authentifizierungstags, Schlüssellängen, Codierung und Fehlerbehandlung sind wichtig.
Kryptografische APIs stellen bekanntermaßen scharfe Werkzeuge mit professionell gefertigten Griffen bereit. Die korrekte Verwendung gehört zum Design.
Die erwartete sichere Form ist, sofern der tatsächliche Code sie unterstützt, eine Anfrage mit Chiffretext und betrieblichen Einstellungen statt mit lesbarem Nachrichtentext.
Prüfen Sie das Netzwerkfenster des Browsers. Leiten Sie diese Eigenschaft nicht aus Texten der Benutzeroberfläche ab.
Diese Werte sind nicht automatisch geheim. Einige werden für die Entschlüsselung benötigt und können den Chiffretext sicher begleiten. Der Schlüssel ist der entscheidende Unterschied.
Ein sicherer Link ist nicht automatisch harmlose Metadaten. Wenn der vollständige Link die Entschlüsselung ermöglicht, ist er eine Bearer-Berechtigung: Jeder, der ihn besitzt, kann die Nachricht möglicherweise öffnen.
Behandeln Sie den Link daher während seiner kurzen Lebensdauer ungefähr mit derselben Sorgfalt wie das Geheimnis.
Das ist wichtig, weil automatisierte Systeme Links anfordern können. Eine einfache GET-Anfrage kann von einem Vorschau-Bot leichter ausgelöst werden als eine ausdrückliche menschliche Aktion, obwohl kein Mechanismus die Menschlichkeit vollkommen beweist.
Der Browser des Empfängers erhält den Chiffretext und das erforderliche Schlüsselmaterial und führt anschließend eine authentifizierte Entschlüsselung durch.
Wenn die Authentifizierung fehlschlägt, sollte die Anwendung melden, dass die Nachricht nicht verifiziert oder entschlüsselt werden konnte. Sie sollte beschädigten Text nicht so anzeigen, als wäre nichts geschehen.
Eine erfolgreiche Entschlüsselung erzeugt Klartext im Browser des Empfängers. Ab diesem Zeitpunkt kann Kryptografie nicht verhindern, dass Kopien, Screenshots, Fotos oder ein infiziertes Gerät die Nachricht erfassen.
Die Verschlüsselung schützt einen Weg. Sie kann das zukünftige Verhalten des Empfängers nicht steuern.
Eine gute Datenschutzseite benennt diese Grenze, statt sie durch „für immer verschwunden“ zu ersetzen.
Die richtige Schlussfolgerung ist nicht Pessimismus, sondern Genauigkeit.
Collogue sollte ein begrenztes Versprechen machen, es durch beobachtbares Verhalten stützen und die Annahmen erklären. Das ist hilfreicher, als ein großes Schloss-Symbol neben einen kurzen Absatz zu setzen.
Nein. Sichere Schlüsselerzeugung, authentifizierte Verschlüsselung, eindeutige Nonces, wo erforderlich, korrekte Codierung, Integritätsprüfungen und sichere Fehlerbehandlung gehören alle zum Protokoll.
Weil die Entschlüsselung auf dem Gerät des Empfängers lesbaren Text erzeugen muss. Kryptografie kann den Zugriff davor kontrollieren, nicht das spätere Verhalten des Empfängers.
Erstellen Sie einen privaten Collogue-Link, wenn Sie ein Passwort, Token, einen Wiederherstellungscode oder einen anderen kurzen sensiblen Wert senden müssen.