Primary local dataEncrypted app storage
Diary data is stored in an encrypted Hive box. Its randomly generated encryption key is kept through Flutter secure storage rather than embedded in ordinary app data.
Boundary: encryption does not protect an already unlocked app or a fully compromised operating system account.
Legal metadataSQLCipher with a separate 256-bit key
Legal-library metadata uses SQLCipher, secure-delete settings and a random per-scope key held in platform secure storage. Production startup verifies that SQLCipher is actually available.
App accessPIN, lockout, biometric approval and relock
PIN verification uses salted iterative HMAC-SHA256 and constant-time comparison. Five failed attempts in the protected window trigger a two-minute lockout. Supported biometric approval can protect launch/Admin actions, and the app can relock after about 30 seconds in the background.
Personal backupAES-256-GCM before local export or Drive upload
A random 256-bit content key encrypts the validated backup. The user recovery key wraps that content key and is not stored in clear text inside the backup.
Recovery boundary: the current format can also include an X25519 support-recovery envelope. The backup is client-side encrypted, but is not described as strictly user-only E2EE.
Chamber collaborationAES-256-GCM content between invited devices
Shared chamber payloads and live signals are encrypted with the chamber key. Invitees receive the key through the invite workflow and decrypt locally. Revocation and key rotation support lost-device response.
Metadata boundary: Google/relay infrastructure can still process account email, folder and permission IDs, membership, timing, file size, IP/network and delivery metadata.
Offline legal documentsPer-document keys, account and device binding
Each protected cached document uses a random data-encryption key and AES-256-GCM. The key is wrapped by Android Keystore, Windows DPAPI for the current user, or secure platform storage fallback. User, device and file-version context are checked before opening.
Legal sessionIdentity, nonce and replay checks
Security-sensitive legal access binds app/package/install and Google-session context, uses timestamp/nonce controls and can clear or lock cache access after repeated security failures.
Sync integrityConflicts are preserved, not silently overwritten
Chamber merge logic records same-field and delete-versus-edit conflicts and lets the authorised user choose local or remote content. Profile switches and other sensitive changes are auditable.
Update channelSigned manifest and artifact checks
Release update metadata requires Ed25519 verification. Downloads use HTTPS, expected file-size controls, SHA-256 verification and Windows installer-signature validation before the installer is accepted.
Storage reliabilityQueued, journaled and validated operations
Backup/sync operations validate payloads, use durable pending state, resume confirmed upload offsets and quarantine or reject invalid data instead of treating malformed content as valid.
