Secret Diary
Download Free
Cryptographic Whitepaper

Zero-Knowledge Security Architecture

We designed Secret Diary with a strict zero-knowledge philosophy: we cannot read your diary entries even if we wanted to, because we mathematically lack the keys.

Core Cryptographic Axiom: The FastAPI backend, database operators, cloud providers, and Plixlify developers operate in a 100% Zero-Knowledge capacity. Plaintext notes never touch the network or our servers under any condition.

1. The Three Cryptographic Keys

To deliver both military-grade confidentiality and safe password recovery without compromising privacy, Secret Diary manages three distinct cryptographic keys:

1. Master Key (Data Encryption Key / DEK)

A cryptographically secure 256-bit symmetric key (AES-256-GCM) generated directly on the user's Android device upon initial setup. This key directly encrypts and decrypts all diary notes, checklists, titles, and media payloads.

2. User Wrapping Key (Key Encryption Key / KEK)

A key derived client-side from the user's password using the memory-hard Argon2id key derivation function, coupled with a 16-byte random salt. This key encrypts the Master Key to form user_wrapped_key. The plaintext password is never stored or transmitted to the server.

3. Server Escrow Keypair (RSA-OAEP-4096 / ECC)

An asymmetric keypair managed securely in the cloud. The Escrow Public Key is fetched by the client during registration to encrypt a duplicate copy of the Master Key (escrow_wrapped_key). The Escrow Private Key is protected in dedicated cloud security vaults and is only accessed during multi-factor identity-verified password reset sessions.

2. Note Payload Encryption Standard (AES-256-GCM)

Every note write, edit, and sync follows strict cryptographic protocols:

  • Unique Initialization Vector: The client application generates a cryptographically random 12-byte IV (nonce) for every individual note modification. No IV is ever reused.
  • AES-256-GCM Authenticated Encryption: Plaintext JSON payloads are encrypted using Galois/Counter Mode (GCM).
  • 16-Byte Authentication Tag: Computes a 128-bit integrity tag. Any bit flipping or data tampering during transmission results in an immediate authentication failure during client-side decryption.
  • Zero-Knowledge Transmission: Only Base64-encoded ciphertext, IV, and auth tag are transmitted over TLS to the backend API.

3. Password Recovery via Key Escrow

Traditional zero-knowledge apps have a catastrophic flaw: if a user forgets their password, their lifetime of personal notes is lost forever. Secret Diary solves this through our secure Server Escrow Architecture:

  1. The user requests a password reset from the Secret Diary app.
  2. A time-limited 6-digit cryptographic OTP is dispatched to the user's verified email.
  3. Upon successful multi-factor OTP verification, the backend briefly uses its Escrow Private Key to decrypt the user's escrow_wrapped_key.
  4. The recovered Master Key is returned to the authenticated client over an encrypted TLS connection.
  5. The client prompts the user for a new password, derives a fresh Argon2id wrapping key, re-encrypts the Master Key, and uploads the new user_wrapped_key.
  6. The server immediately purges all ephemeral memory traces.

4. Native C++ Obfuscation & Reverse-Engineering Defense

Unlike typical Android apps where strings and cryptographic primitives can be easily decompiled using tools like Jadx or APKTool, Secret Diary compiles critical security routines into a native C++ shared library (libnative-lib.so):

  • Compile-time XOR obfuscation with dynamic mask registers.
  • Volatile pointers preventing compiler constant-folding into plaintext string literals.
  • Strict -O3 -fvisibility=hidden compilation flags.
  • Android NDK JNI interface boundaries preventing dynamic memory inspection.

5. Architectural Threat Matrix

Threat Scenario Impact on Secret Diary Protection Mechanism
Cloud Database Leak / Breach Zero Data Leaked Ciphertext only; Master Key is never on the database.
Rogue Server Administrator No Access to Notes Admins cannot decrypt notes without client Master Key.
Physical Phone Theft Protected by Vault Biometric & 6-digit PIN lock on local Android Keystore.
Network Interception (MITM) Payload Unreadable TLS 1.3 encryption + AES-256 payload ciphertext.

6. Independent Audits & Verification

Our cryptographic model was verified through rigorous end-to-end testing, static analysis, and cryptographic payload inspection. All client-to-server contracts conform strictly to modern OWASP and NIST SP 800-38D standards.