Ver- und Entschlüsselung erfolgen lokal mit Web Crypto und dem entsperrten Tresorschlüssel.
So schützt EncDiary deine Daten
Diese Seite beschreibt, was Ende-zu-Ende verschlüsselt ist, welche Informationen der Server weiterhin sieht und wo die technischen Grenzen liegen.
Technischer Stand: E2EE-Tagebuch v2 + verschlüsselter Kalender · kein unabhängiges Audit
01
Architektur auf einen Blick
Klartexte von Tagebuch und Terminen sowie der entsperrte Schlüssel bleiben im Browser.
AES-256-GCMnur Geheimtext
Der Server speichert den verschlüsselten Inhalt, erhält aber nicht den entsperrten Tagebuchschlüssel.
Was der Server nicht sieht
- Titel und Tagebuchtexte im Klartext
- Stimmung, Tags und Körpermaße innerhalb des verschlüsselten Eintrags
- Termintitel, Notizen, Orte, Praxen, Ärzt*innen und medizinische Fachrichtungen
- Den entsperrten Tagebuchschlüssel
- Deinen Wiederherstellungsschlüssel
- Ein dauerhaft gespeichertes Kontopasswort im Klartext
Was der Server sieht
- Kontoinformationen; eingegebene Passwörter werden bei Login und Re-Authentifizierung verarbeitet, aber nicht im Klartext gespeichert
- Zuordnung, Datum, Uhrzeit, Revision und Verschlüsselungsstatus von Tagebucheinträgen und Terminen
- Verschlüsselte Inhalte, IVs und Wrapped-Key-Envelopes
- Forenbeiträge, News und andere ausdrücklich nicht E2EE-geschützte Bereiche
- Technische Anfrage- und anonymisierte Nutzungsdaten im beschriebenen Umfang
02
Eingesetzte Kryptografie
Bezeichnungen und Parameter der aktuellen Implementierung.
256-Bit-Tagebuchschlüssel, zufälliger 12-Byte-IV und 16-Byte-Authentifizierungs-Tag.
Bindet den Geheimtext kryptografisch an seinen Eintragskontext.
Termindetails verwenden denselben entsperrten 256-Bit-Tresorschlüssel, aber bei jeder Verschlüsselung einen eigenen zufälligen 12-Byte-IV.
Verhindert, dass ein gültig verschlüsselter Termin unbemerkt einem anderen Terminkontext zugeordnet wird.
Ein 16-Byte-Salt leitet im Browser den 256-Bit-Wrapping-Key ab.
Der Server erhält nur passwort- und recovery-geschützte Tagebuchschlüssel.
Serverseitiger Einweg-Hash; der konkrete Algorithmus folgt der installierten PHP-Version.
XSalsa20-Poly1305 oder AES-256-GCM mit Serverschlüssel; daher keine E2EE.
Recovery und Passwortänderung
Die Recovery-Datei enthält einen separaten zufälligen Schlüssel. Bewahre sie offline und geschützt auf. Bei der Erstellung wird sie nicht im Klartext hochgeladen.
Bei einer Passwortänderung wird der Tagebuchschlüssel im Browser neu verpackt. Altes und neues Passwort werden zusätzlich über HTTPS an den Konto-Endpunkt gesendet, weil der Server das bisherige Kontopasswort prüfen und einen neuen Passworthash speichern muss. Tagebucheinträge werden dabei nicht im Klartext hochgeladen.
Wenn der Zugriff verloren geht
Wenn sowohl Passwort als auch Recovery-Datei verloren sind, kann EncDiary weder Tagebucheinträge noch Termindetails entschlüsseln. Auch Administratoren können den Tresorschlüssel nicht zurücksetzen oder rekonstruieren.
Eine verlorene Recovery-Datei allein ist kein Problem, solange der Tresor noch mit dem aktuellen Passwort entsperrt werden kann.
03
Bedrohungsmodell
Wogegen das aktuelle Design schützen soll – und wogegen es allein nicht schützen kann.
Diebstahl der Datenbank
Ein Angreifer erhält Geheimtexte, Metadaten und Wrapped-Key-Envelopes, aber keinen Klartext. Das Envelope ermöglicht Offline-Passwortversuche; PBKDF2 verteuert sie, ein starkes Passwort bleibt dennoch entscheidend.
Manipulation von Geheimtexten
AES-GCM-Authentifizierung und AAD führen dazu, dass manipulierte oder vertauschte Tagebucheinträge und Termine nicht entschlüsselt werden.
Angreifer im Netzwerk
Produktives HTTPS schützt den Transport. Tagebuchinhalte bleiben zusätzlich verschlüsselt; Kontozugangsdaten sind dennoch auf korrektes TLS angewiesen.
Kompromittierte Anwendung oder Gerät
Schädlicher, vom Server ausgelieferter Code, Malware oder eine Browser-Erweiterung kann nach dem Entsperren auf Klartext zugreifen.
04
Bekannte Grenzen
Ende-zu-Ende-Verschlüsselung ist ein starker Schutz, aber kein Versprechen absoluter Sicherheit.
- Ein kompromittiertes Gerät oder eine schädliche Browser-Erweiterung kann nach dem Entsperren auf Inhalte zugreifen.
- Dem vom Server ausgelieferten Anwendungscode muss vertraut werden; Security-Header reduzieren Browserrisiken, beseitigen aber nicht jede Schwachstelle.
- Metadaten wie Datum und Uhrzeit werden durch das aktuelle E2EE-Design nicht verborgen.
- Termintitel, Notizen, medizinische Angaben und Orte sind Ende-zu-Ende verschlüsselt. Für die Kalenderbereitstellung sieht der Server Benutzer-ID, Datum, Uhrzeit und den verschlüsselten Umschlag.
- Browser, Betriebssystem und Recovery-Sicherung sollten geschützt und aktuell gehalten werden.
- Die Implementierung wurde nicht unabhängig auditiert oder formal verifiziert. Diese Seite dokumentiert das umgesetzte Design und ist keine Zertifizierung.