cryptlite encrypts sensitive locally persisted payloads at rest using OS-protected keys. Queryable operational metadata must be stored separately as normal SQLite columns.
- Someone copying the SQLite database file and reading it offline — encrypted blobs are unreadable without the OS keychain
- Accidental exposure of raw JSON payloads in backups, sync tools, or disk images
- Basic at-rest inspection by tools that read SQLite directly
- A compromised running process on the same machine
- Malware or other software running as the same OS user
- A debugger attached to the process
- Plaintext data stored by other tools or logs on the same machine
- Memory dumps while the process is running
- An OS user with live access after the keychain has been unlocked
- An attacker with full disk access on a running, unlocked system
The master encryption key is stored in the OS keychain:
- macOS: Keychain
- Windows: Credential Manager
- Linux: Secret Service (libsecret-compatible backend)
The library uses envelope-style encryption: the OS keychain holds a 256-bit AES key, each encrypted blob stores its own random 12-byte GCM nonce and a key version reference. Rotating the key creates a new keychain entry; old entries remain for decrypting existing rows.
The library binds each ciphertext to a context (table name + column name + row ID) using GCM additional authenticated data. This prevents an attacker from copying a ciphertext from one row to another without detection — decryption will fail if the AAD does not match.
Queryable fields are extracted and stored as normal SQLite columns before insert. Encrypted blobs are never used in SQL predicates. This means an adversary with access to the SQLite file can see query metadata (timestamps, IDs, extracted fields) but not the encrypted raw payloads.