Verschlüsselungsschlüssel
Wo befindet sich der Entschlüsselungsschlüssel?
Warum Collogue ein separat eingegebenes Passwort verwendet, statt den Schlüssel in die URL zu legen.
Veröffentlicht: 28. Februar 2026
Grenzen der aktuellen Implementierung
Der aktuelle Client verschlüsselt den Text im Browser und legt den verschlüsselten Inhalt in der URL ab. Das separat geteilte Passwort gehört nicht zum Link. Es gibt keinen Anwendungsserver zum Speichern, Abrufen, Löschen oder als Einmalansicht für Nachrichten.
Weiterer Kontext
Verschlüsselung ersetzt ein schwieriges Problem durch ein anderes.
Schlüssel sind klein. Ihre Folgen sind es nicht.
Ein symmetrischer Verschlüsselungsschlüssel ermöglicht es dem Browser des Empfängers, authentifizierten Chiffretext wieder in Klartext umzuwandeln.
``text https://collogue.net/m/example-message#example-key-material ``
Verwenden Sie dieses Beispiel nur, wenn es zur tatsächlichen Architektur passt.
Das Fragment ist der Teil einer URL nach #.
``text https://example.test/message/123#key-material ``
``text /message/123 ``
Der Browser behält #key-material lokal und stellt es der geladenen Seite zur Verfügung.
Dabei sind drei Warnungen wichtig.
Erstens kann das von der Seite geladene JavaScript das Fragment lesen. Browserseitige Entschlüsselung benötigt dies oder einen gleichwertigen Mechanismus.
Zweitens ist der vollständige Link nun eine Berechtigung. Jeder, der ihn erhält, kann sowohl den Verweis auf den Chiffretext als auch den Schlüssel bekommen.
Drittens können Fragmente durch menschliches Verhalten, Screenshots, kopierten Text, Browser-Erweiterungen, Zwischenablageverlauf, Synchronisierungswerkzeuge oder veränderten Client-Code trotzdem offengelegt werden.
Ein Fragment ist eine nützliche Protokollgrenze. Es ist kein Kraftfeld.
- Zugriffsprotokolle;
- Reverse-Proxy-Protokolle;
- Browserverlauf;
- kopierte Diagnosedaten;
- Referrer-Daten, abhängig von Richtlinie und Navigation;
- Überwachungssysteme.
In diesem Fall muss der öffentliche Artikel die tatsächliche Offenlegung erklären, statt das Verhalten von Fragmenten zu beschreiben.
Eine einprägsame Passphrase und ein gleichförmig zufälliger Schlüssel sind nicht austauschbar. Die Parameter der Ableitung sind wichtig.
Benutzer nehmen manchmal an, ein verschlüsselter Link könne öffentlich gepostet werden, weil er „nur verschlüsselte Daten enthält“.
Diese Schlussfolgerung ist falsch, wenn der Link zugleich die Berechtigung zur Entschlüsselung liefert.
- öffentliche Issue-Tracker;
- gemeinsame Kanäle mit unnötigen Mitgliedern;
- URL-Analyse-Dienste;
- öffentliche URL-Kürzer;
- Dokumente mit weitreichendem Zugriff.
Der Besitz des Links kann den Besitz des Links belegen. Er stellt nicht unbedingt eine Identität fest.
Wenn ein Angreifer die URL vor dem vorgesehenen Empfänger erhält, kann die Kryptografie für den Angreifer vollkommen korrekt funktionieren.
Das ist die wiederkehrende Lehre von Bearer-Berechtigungen: Die Berechtigung wird durch Besitz dargestellt.
Bei Geheimnissen mit höherem Risiko prüfen Sie den Empfänger und erwägen Sie einen separaten Kanal für Kontext oder zusätzliche Authentifizierung. Beschreiben Sie getrennte Kanäle nicht automatisch als sicher; sie verändern lediglich die Anforderungen an einen Angriff.
- der Absender teilt den falschen Link;
- der Empfänger leitet ihn weiter;
- Browser-Schadsoftware liest das Fragment;
- ein bösartiges Seitenskript erfasst Klartext;
- der Zwischenablageverlauf bewahrt die URL auf;
- ein Link-Scanner fordert die Seite an;
- der Empfänger speichert die entschlüsselte Nachricht.
Das kann ein nützliches Design sein, weil das Fragment normalerweise nicht in HTTP-Anfragen gesendet wird. Die Sicherheit hängt trotzdem von der ausgelieferten Seite, der Browserumgebung, der Linkverarbeitung und dem Verhalten des Empfängers ab.
Ja. JavaScript, das auf der Seite ausgeführt wird, kann auf das Fragment zugreifen. So erhält clientseitige Entschlüsselung häufig das Schlüsselmaterial.
Wenn Collogue den Schlüssel nicht aufbewahrt oder ableitet, kann der Verlust des erforderlichen Linkmaterials die Nachricht unwiederbringlich machen. Bestätigen Sie die Implementierung, bevor Sie diese Aussage veröffentlichen.