Zero-Knowledge Design for a Private Diary App

I started digital journaling years ago, but quickly realized I was self-censoring. The knowledge that my private thoughts resided in plaintext on remote servers—accessible to developers, vulnerable to database breaches, and susceptible to AI profiling—fundamentally changed how honestly I wrote.

That realization led to the creation of RozVibe. I wanted an encrypted diary where privacy was designed into the architecture natively, helping minimize reliance on a trust-based privacy policy.

RozVibe's security architecture is publicly documented because privacy designs should be verifiable. Users deserve to understand how their data is protected.

Transparency is a core part of building trust. We believe users have the right to know how data is encrypted, where that encryption occurs, what assumptions the system makes, and what limitations exist within the security model.

In our privacy-first journaling model, encryption is applied before data leaves the device. Firestore does not receive journal plaintext. Instead, Firestore stores only base64-encoded ciphertext payloads.

We rely on AES-256-GCM to protect both the confidentiality and integrity of your encrypted notes. This helps prevent tampering or passive decryption by untrusted infrastructure.

A critical component of a client-side encryption model is key management. In RozVibe, keys are reconstructed locally, not retrieved from a remote server.

• The local application derives keys from user credentials and holds them temporarily in memory (RAM).
• Reconstructed keys are used for session tasks and are cleared from RAM upon logout or when the session is closed.
• Keys are generated on login and immediately wiped from RAM on logout.
• Encryption keys are **not stored** in Firestore, and are **not stored** in local SharedPreferences.

To transform a user's password into strong cryptographic material, RozVibe utilizes PBKDF2-HMAC-SHA256 with 100,000 iterations. This iteration count deliberately slows down the derivation process, helping protect against offline brute-force and dictionary attacks by making them computationally expensive.

Password Security

Because keys are derived directly from user credentials, your choice of password is the most critical factor in securing your journal. We recommend using a long, unique password that is not reused across other accounts. While our implementation of PBKDF2 with 100,000 iterations significantly raises the cost of dictionary attacks, it cannot fully compensate for weak, short, or compromised passwords.

The Encryption Flow:

In our client-side encryption model, Firestore acts as an encrypted cloud storage layer. It receives only base64-encoded ciphertext payloads and essential routing metadata. Firestore does not receive or store plaintext journal entries.

Below is an illustrative, simplified JSON representation of an encrypted document document schema stored in the cloud:

Multi-device sync works through deterministic key reconstruction. When logging into a secondary device, the application retrieves your unique cryptographic salt from Firestore, prompts for your password, and re-derives the identical AES key locally. This enables synchronization across your devices without storing or exposing keys on the server.

Search functionality poses a unique challenge in client-side encrypted systems. In RozVibe, search queries are processed locally. The current implementation relies on client-side search: the local application decrypts records into RAM and performs keyword matching entirely on-device.

To support larger journal databases efficiently, we are designing a blind index search architecture using HMAC-SHA256 token hashes. In this model, the local SQLite cache will store deterministic token hashes of words rather than plaintext journal words. This is intended to allow the local database to resolve searches without needing to decrypt the entire vault into memory, helping protect privacy bounds.

Cryptography is a powerful tool for protecting data, but it operates within a larger ecosystem. The security of RozVibe depends on several assumptions and contains inherent limits:

• Device Integrity: We assume the user's device is free from active spyware, keyloggers, and malware. If the operating system is compromised, cryptographic protections can be bypassed by capturing inputs or memory contents directly.
• Operating System Sandbox: On heavily modified or rooted devices, the standard application sandbox defenses provided by Android may be weakened, increasing the risk of local database access by unauthorized apps.
• Password Entropy: The strength of the derived encryption key is limited by the password's strength. Weak, short, or common passwords can be broken by dictionary attacks if an attacker obtains the encrypted database.
• Physical Security: If an adversary gains physical access to your device while it is unlocked and the application is open, they can read your entries. Encryption protects data at rest, not active sessions.

Understanding these boundaries is crucial for maintaining a realistic security posture. No software system can eliminate every possible threat vector.

In cryptography, architecture choices involve balancing security, usability, and recoverability.

The Trade-Off: The cryptographic salt used for PBKDF2 derivation is stored in Firestore alongside the encrypted payload.

The Alternative: We could have implemented a strict user-managed key backup system, requiring users to safely store a recovery key offline.

Why We Chose This: We prioritized recoverability and multi-device synchronization. Storing the salt in Firestore allows a user to log into a new device and reconstruct their keys locally using their password. While an offline key approach provides tighter boundaries, the risk of a user losing their recovery key (and irrevocably losing all their journal entries) was deemed to outweigh the risk of salt exposure, as the derived key remains protected by the entropy of the user's password.

We believe that security is an ongoing, collaborative process. We invite security researchers, cryptographers, and privacy advocates to analyze our architecture, review our implementation, and report any findings.

If you identify a potential vulnerability, please contact us securely at roninytbusiness@gmail.com. We prioritize investigating and remediating responsibly disclosed issues.