Encryption and decryption take place locally using Web Crypto and the unlocked vault key.
How EncDiary protects your data
This page describes what is end-to-end encrypted, which information remains visible to the server, and where the technical limits are.
Technical status: E2EE diary v2 + encrypted calendar · no independent audit
01
Architecture at a glance
Diary and appointment plaintext as well as the unwrapped key remain in the browser.
AES-256-GCMciphertext only
The server stores the encrypted payload but does not receive the unwrapped diary key.
What the server cannot see
- Plaintext titles and diary text
- Mood, tags and body measurements stored inside the encrypted entry
- Appointment titles, notes, locations, practices, doctors and medical specialties
- The unwrapped diary key
- Your recovery key
- A permanently stored plaintext account password
What the server can see
- Account information; submitted passwords are processed during login and re-authentication but are not stored as plaintext
- Diary entry and appointment ownership, date, time, revision and encryption status
- Encrypted payloads, IVs and wrapped-key envelopes
- Forum posts, news and other explicitly non-E2EE areas
- Technical request and anonymized usage data described by the service
02
Cryptographic building blocks
The names and parameters used by the current implementation.
256-bit diary key, random 12-byte IV and 16-byte authentication tag.
Cryptographically binds ciphertext to its entry context.
Appointment details use the same unlocked 256-bit vault key but an independent random 12-byte IV for every encryption.
Prevents a valid encrypted appointment from being silently assigned to another appointment context.
A 16-byte salt derives the browser-side 256-bit wrapping key.
The server receives only password- and recovery-wrapped diary keys.
One-way server hash; the concrete algorithm follows the installed PHP runtime.
XSalsa20-Poly1305 or AES-256-GCM with a server key; therefore not E2EE.
Recovery and password changes
The recovery file contains a separate random key. Keep it offline and private. It is not uploaded as plaintext when it is created.
When the account password changes, the diary key is re-wrapped in the browser. The old and new password are also sent over HTTPS to the account endpoint because the server must verify the old account password and store a new password hash. Diary entries themselves are not uploaded in plaintext.
If access is lost
If both the password and recovery file are lost, EncDiary cannot decrypt diary entries or appointment details. Administrators cannot reset or reconstruct the vault key.
A lost recovery file alone is not a problem while the current password still unlocks the vault.
03
Threat model
What the current design is intended to protect against—and what it cannot protect against by itself.
Database theft
An attacker receives ciphertext, metadata and wrapped-key envelopes, but not plaintext. The envelope permits offline password guesses; PBKDF2 makes them more expensive but a strong password remains essential.
Ciphertext manipulation
AES-GCM authentication and AAD cause modified or context-swapped diary entries and appointments to fail decryption.
Network attacker
Production HTTPS protects transport. Diary content additionally remains encrypted, but account credentials still rely on correct TLS operation.
Compromised application or device
Malicious code delivered by the server, malware or a browser extension can access plaintext after the vault is unlocked.
04
Known limits
End-to-end encryption is strong protection, not a promise of absolute security.
- A compromised device or malicious browser extension may access content after the vault has been unlocked.
- Application code delivered by the server must be trusted; security headers reduce browser risks but cannot eliminate every vulnerability.
- Metadata such as entry date and time is not hidden by the current E2EE design.
- Appointment titles, notes, medical information and locations are end-to-end encrypted. The server can see the user ID, date, time and encrypted envelope required for calendar delivery.
- Keep the browser, operating system and recovery backup protected and up to date.
- The implementation has not been independently audited or formally verified. This page documents the implemented design, not a certification.