OneTimeSecret vs PrivateNote: Why Where You Encrypt Matters

Zwei Wege, denselben Link zu bauen

Bei serverseitiger Verschlüsselung übermittelt der Absender das Geheimnis über TLS an den Dienst. Der Dienst empfängt den Klartext, verschlüsselt ihn und speichert Chiffretext. Anschließend kann er die Nutzlast speichern, ausliefern, ablaufen lassen und löschen. Der Anwendungsserver ist Teil des Verschlüsselungsprozesses, weil Klartext in den Dienst gelangt, bevor daraus Chiffretext wird.

Bei clientseitiger Verschlüsselung verschlüsselt zuerst das Gerät des Absenders. Der Dienst empfängt und speichert Chiffretext. Dieser Upload läuft über TLS. Der Dienst erhält nicht den Schlüssel, der nötig wäre, um eine Standard-Nutzlast zu entschlüsseln. Das Gerät des Empfängers entschlüsselt lokal. Der Dienst kann die Nutzlast weiterhin speichern, ausliefern, ablaufen lassen und löschen, ohne Zugriff auf ihren Klartext zu brauchen.

Beide Designs können temporäre Links, begrenzten Zugriff und Ablaufzeiten bieten. Beide lassen sich korrekt als verschlüsselt beschreiben. OneTimeSecret nutzt die erste Architektur; PrivateNote die zweite. Die relevante Frage ist daher nicht einfach, ob ein Einmal-Link verschlüsselt ist, sondern welche Systeme Zugriff auf Klartext haben müssen, damit dieser Link funktioniert.

OneTimeSecret: serverseitige Verschlüsselung

Im gewöhnlichen OneTimeSecret-Ablauf übermittelt der Absender das Geheimnis über TLS. Die Anwendung empfängt den Klartext, verschlüsselt ihn auf dem Server und speichert die verschlüsselte Nutzlast.

Das bietet einen sinnvollen Schutz für gespeicherte Daten. Allein der Besitz verschlüsselter Speicherung offenbart den Inhalt nicht zwingend, wenn dem Angreifer das zur Entschlüsselung nötige Material fehlt.

Der architektonische Kompromiss entsteht vor dem Speichern. TLS schützt das Geheimnis auf dem Weg zwischen Browser und OneTimeSecret, aber die Anwendung muss den Klartext verarbeiten, um ihn zu verschlüsseln. Der Anwendungsserver liegt daher innerhalb der kryptografischen Vertrauensgrenze.

Ein bösartiger oder kompromittierter Anwendungsprozess könnte in diesem Moment auf das Geheimnis zugreifen, bevor es für die Speicherung verschlüsselt wird. Clientseitige Verschlüsselung entfernt genau diese Abhängigkeit, indem das Geheimnis verschlüsselt wird, bevor es den Dienst erreicht.

Die Passphrase von OneTimeSecret ändert die Verschlüsselungsgrenze nicht

Die Dokumentation von OneTimeSecret beschreibt eine optionale Passphrase. Wird eine Passphrase verwendet, verschlüsselt OneTimeSecret laut eigener Aussage das Geheimnis auf seinen Servern mit der vom Absender gelieferten Passphrase. Die Passphrase selbst wird nicht gespeichert; stattdessen behält OneTimeSecret einen bcrypt-Hash zur Überprüfung der Passphrase beim Abruf. Laut Dokumentation kann dieser Hash das Geheimnis selbst nicht entschlüsseln, und das gespeicherte, passphrase-geschützte Geheimnis lässt sich ohne die Original-Passphrase nicht entschlüsseln.

Der Abruf nutzt dieselbe serverseitige Grenze. Der Empfänger übermittelt die Passphrase über TLS an OneTimeSecret. Der Dienst prüft sie und führt die Entschlüsselung auf dem Server durch, bevor der Klartext zurückgegeben wird.

Das bedeutet: Der Anwendungsprozess hat Zugriff auf Geheimnis und Passphrase, wenn die Verschlüsselung stattfindet, und verarbeitet beim Abruf erneut die Passphrase und den resultierenden Klartext. Ein bösartiger oder kompromittierter Anwendungsprozess an einem dieser Punkte könnte diese Informationen potenziell erfassen. Das ist eine Folge davon, wo Verschlüsselung und Entschlüsselung ausgeführt werden — kein Vorwurf, dass OneTimeSecret diese Werte speichert oder missbraucht.

Die öffentliche Dokumentation von OneTimeSecret legt für sich genommen nicht jedes Detail der internen Schlüsselhierarchie fest — etwa, wie genau serverseitiges Schlüsselmaterial, Schlüssel pro Geheimnis, Schlüsselableitung und die gelieferte Passphrase kombiniert werden. Für diesen Vergleich muss man über diese Implementierungsdetails nicht spekulieren. Die relevante dokumentierte Eigenschaft ist, dass Verschlüsselung und Entschlüsselung auf der Seite des Dienstes stattfinden.

Self-Hosting kann dieses Serververtrauen vertretbar machen

OneTimeSecret ist Open Source. Eine Organisation kann eine eigene Instanz innerhalb eines Unternehmens-Sicherheitsperimeters betreiben, statt Geheimnisse an den öffentlichen Dienst zu senden.

In diesem Deployment bedeutet Vertrauen in den Anwendungsserver Vertrauen in Infrastruktur, die die Organisation bereits betreibt. Der Klartext erreicht diesen Server weiterhin, weil die Verschlüsselung weiterhin dort stattfindet. Die Partei auf der anderen Seite der Grenze sind die eigenen Hosts, Betreiber und Backups der Organisation. Für ein Team, das diese Systeme bereits als Teil des Pfads akzeptiert, den ein Geheimnis nimmt, kann serverseitige Verschlüsselung eine vernünftige Wahl sein. Sie verringert den Abstand zwischen den serverseitigen und clientseitigen Bedrohungsmodellen, weil der Betreiber kein externer Dienst mehr ist.

PrivateNote verschlüsselt vor dem Upload

Eine Standard-PrivateNote wird vor dem Upload verschlüsselt. Der Browser des Absenders — oder ein lokaler CLI-, Chrome-Erweiterung-, Editor-Erweiterung- oder MCP-Prozess — erzeugt einen zufälligen Schlüssel und verschlüsselt die Nutzlast mit AES-256-GCM. Hochgeladen wird nur Chiffretext. TLS transportiert diesen Chiffretext vom Browser zum Cloudflare-Worker von PrivateNote. Der Entschlüsselungsschlüssel liegt im URL-Fragment, dem Teil nach #, zum Beispiel https://privatenote.ai/note/abc123#…. Das Fragment wird clientseitig verarbeitet und ist nicht in der HTTPS-Anfrage enthalten (RFC 3986, §3.5; URL Standard). Der Worker empfängt eine Notiz-ID und gibt Chiffretext über dieselbe TLS-Verbindung zurück. Der Browser behält das Fragment und entschlüsselt lokal.

Eine Passphrase schützt den Schlüssel, wenn der Link-Kanal kompromittiert ist

Eine Passphrase bei PrivateNote erfüllt eine andere Aufgabe als eine Passphrase bei OneTimeSecret. Die Notiz ist bereits Chiffretext, bevor sie das Gerät verlässt. Fügen Sie eine Passphrase hinzu, leitet der Browser daraus mit Argon2id einen Wrapping-Schlüssel ab und verschlüsselt damit den Notizschlüssel. Das URL-Fragment hält dann den eingewickelten Schlüssel. Der Empfänger braucht den Link und die Passphrase. Der Browser wickelt den Schlüssel lokal aus und entschlüsselt erst dann die Notiz.

PrivateNote empfängt die Passphrase nicht. Die Create-Anfrage trägt Chiffretext, ein Salt und die Parameter, die der Browser des Empfängers braucht, um die Passphrase lokal zu versuchen. Es gibt keinen serverseitigen Hash, dessen Aufgabe die Passphrase-Prüfung wäre. Eine falsche Passphrase scheitert bei der Entschlüsselung auf dem Gerät.

Die Passphrase schützt den clientseitigen Schlüssel zusätzlich lokal, wenn der Kanal, der den Link trägt, kompromittiert wird. Dieser Kanal sieht dann einen eingewickelten Schlüssel, keinen Schlüssel, der die Notiz allein öffnen kann. Das ist nicht der Mechanismus, der PrivateNote außerhalb des Klartext-Pfads hält. Diese Trennung besteht bei einer Standard-Notiz bereits — mit oder ohne Passphrase. Teilen Sie die Passphrase über einen anderen Kanal als den Link. Dieselbe Nachricht kollabiert die beiden Schichten zu einer — dieselbe Regel wie beim sicheren Teilen eines Passworts.

Die Schlüsselbehandlung von PrivateNote ist unter So funktioniert es beschrieben: Der Inhaltsschlüssel wird mit Argon2id eingewickelt, und der eingewickelte Schlüssel reist im Link.

Die verbleibende Vertrauensannahme beim Web-Client

Clientseitige Verschlüsselung im Browser ist keine vertrauenslose Webanwendung. Die Kryptografie kann lokal laufen, während das JavaScript, das sie implementiert, von der Website ausgeliefert wird. Der Browser vertraut dem Code, den er für diese Sitzung erhält.

Wer dieses JavaScript ändern kann — über die Anwendung, ein CDN oder die Deployment-Pipeline — könnte den Client verändern und in einer künftigen Browser-Sitzung Schlüssel erfassen. Das ist ein anderer Fehler als der Diebstahl einer Datenbank. Eine Speicher-Kompromittierung legt Chiffretext offen. Bösartige Code-Auslieferung greift den Endpunkt an, während der Schlüssel tatsächlich vorhanden ist.

Ein späterer Datenbank-Dump kann keine clientseitigen Schlüssel erzeugen, die dort nie gespeichert waren. Ein aktiv kompromittierter Client kann Geheimnisse angreifen, die in dieser Sitzung verarbeitet werden. Dieselbe Annahme steht im Bedrohungsmodell von PrivateNote: Der ausgelieferte Anwendungscode wurde nicht böswillig verändert, und die Geräte von Absender und Empfänger sind im Moment von Verschlüsselung und Entschlüsselung vertrauenswürdig.

Installierte Software verringert die Abhängigkeit von einer frisch heruntergeladenen Seite. Eine CLI, eine Editor-Erweiterung oder eine native App führt Code aus, den Sie installiert haben. Diese Clients hängen weiterhin vom Betriebssystem, von Signierung, Abhängigkeiten und dem Update-Kanal ab. Die Entwickler-Tools nutzen dieselbe Trennung wie der Browser: lokal verschlüsseln, Chiffretext hochladen, den Schlüssel im Fragment belassen.

Lebensdauer und Vertraulichkeit

Ein Einmal-Link beantwortet zwei getrennte Fragen. Wie lange soll die verschlüsselte Nutzlast existieren? Und wer kann sie entschlüsseln, solange sie existiert? Zerstörung nach Abruf oder Ablauf verkürzt das Fenster. Sie entscheidet nicht, wer sie in diesem Fenster lesen könnte. Lebensdauer und Vertraulichkeit stützen einander. Das eine ersetzt das andere nicht.

Die Unterscheidung wird am schärfsten, wenn die Nutzlast Autorität ist: API-Schlüssel, Datenbank-Zugangsdaten, Cloud-Tokens, Recovery-Codes, Infrastruktur-Passwörter. Ein Secret-Sharing-Dienst existiert, weil der Absender weniger Systemen diese Information anvertrauen will. Wenn der Vermittler nur ein undurchsichtiges verschlüsseltes Objekt tragen, Ablauf erzwingen und löschen muss, kann der Server diese Arbeit leisten, ohne das Geheimnis oder den Schlüssel zu erhalten, der es öffnet.

Wo die Grenze liegt

„Verschlüsselt“ sagt nicht, wo die Vertrauensgrenze liegt. Der brauchbare Maßstab ist eine minimale Vertrauensgrenze: das Prinzip der geringsten Rechte angewandt darauf, wer Klartext sehen muss. In der modernen kryptografischen Technik geht es nicht nur darum, dem Verhalten eines Servers zu vertrauen, sondern die mathematische Notwendigkeit von Vertrauen von vornherein zu verringern.

OneTimeSecret beschreibt ein serverseitig verschlüsseltes System. Mit Passphrase-Schutz sagt es, dass das gespeicherte Geheimnis anschließend ohne die Passphrase nicht entschlüsselt werden kann und dass eine Server-Kompromittierung das Geheimnis sicher ließe, solange diese Passphrase unbekannt bleibt. Eine schwache Passphrase kann per Brute-Force angegriffen werden. Ist sie schwach, kann die Kompromittierung das Geheimnis trotzdem wiederherstellbar lassen. Klartext und Passphrase erreichen OneTimeSecret bei der Erstellung, weil die Verschlüsselung auf dessen Servern stattfindet, und die Passphrase wird beim Abruf zurückgeschickt, damit diese Server entschlüsseln können.

PrivateNote trifft eine andere architektonische Wahl. Die Nutzlast wird verschlüsselt, bevor sie den Dienst erreicht, und der Standard-Nutzlastschlüssel bleibt clientseitig. Eine Passphrase, wenn Sie eine setzen, schützt diesen clientseitigen Schlüssel zusätzlich lokal, wenn der Kanal, der den Link trägt, kompromittiert wird. Sie wird nicht an PrivateNote gesendet.

OneTimeSecret verschlüsselt Ihr Geheimnis. Der Client, der den PrivateNote-Dienst nutzt, verschlüsselt es, bevor der Dienst es erhält. Diese Unterscheidung hängt nicht davon ab, einen der Anbieter als böswillig anzunehmen. Sie reduziert die Frage auf Architektur: Wie viele Systeme brauchen Zugriff auf Klartext, damit der Dienst funktioniert?

Häufige Fragen

Primärquellen

Architekturinformationen zu OneTimeSecret wurden am 23. September 2026 gegen die öffentliche Dokumentation geprüft. Produktimplementierungen und Dokumentation können sich ändern.

• OneTimeSecret documentation
• OneTimeSecret on security and passphrases
• OneTimeSecret source code
• So funktioniert die Verschlüsselung von PrivateNote
• PrivateNote für Entwickler, einschließlich der CLI
• RFC 3986, section 3.5, das das Fragment vor der Dereferenzierung von der URI trennt
• URL Standard, fragment, zur clientseitigen Behandlung des Fragments