Lockpic
Your pattern participates in the key.
Lockpic does not save a password and then compare future attempts against it. A valid 5×5 pattern is encoded and fed into a key-derivation process. The result identifies and unlocks one vault.
Argon2id derives a 32-byte root key using 64 MiB of memory, three iterations, and parallelism four.
An HMAC key held by Android Keystore peppers the derived root. Hardware backing depends on the device and is not currently required or independently verified by Lockpic.
HKDF-SHA256 derives separate values for vault identification and key wrapping. A random AES-256 vault master key protects the vault rather than using the pattern directly on every file.
A pattern is easier to observe or guess than a long random password. Lockpic requires new patterns to span the grid and change direction, and applies a global cooldown after repeated attempts. Physical observation remains outside its protection.
Files are encrypted before they rest.
Small records and key wrappers use AES-256-GCM. Photos and videos use authenticated streaming encryption with one-megabyte segments, allowing video seeking without writing a plaintext playback file.
- Vault metadata is encrypted and padded in 64 KiB buckets.
- Thumbnails are encrypted separately.
- Decrypted image disk caching is disabled.
- Memory caches are cleared when the vault locks.
- Authentication failures are treated as corruption rather than silently overwritten.
No master list of real vaults.
Every valid pattern derives a vault identifier. A pattern can open an existing vault or an empty in-memory space, so the interface does not need a saved list of “correct” patterns.
Encrypted media from all vaults shares flat blob and thumbnail pools. Random chaff makes simple file counting less useful. This supports plausible deniability, but it does not make the app installation, total encrypted size, or all storage patterns invisible to a forensic examiner.
Recovery has two separate jobs.
A 12-word recovery phrase can rebind a vault that still exists on the phone after the pattern or Android Keystore state is lost. It cannot recreate media that no longer exists.
Recovery after a lost, wiped, or uninstalled phone requires both the phrase and an exported encrypted Lockpic backup. Restore verifies and stages the complete backup before publishing it as a vault.
Anyone holding both a recovery phrase and its matching backup can restore that vault. Store them in separate trusted locations.
Protection continues while the app runs.
- Release builds block ordinary screenshots, screen recording, and recents previews.
- The session locks when Lockpic backgrounds or reaches its inactivity timeout.
- Android backup and device-transfer extraction are disabled.
- Imports use Android's system Photo Picker; exports use the system Storage Access Framework.
- Storage operations hold a short-lived session lease so keys are not erased midway through a write.
What this design does not promise.
Lockpic does not protect against a rooted or compromised operating system reading a live unlocked process, an attacker who knows the real pattern or phrase, privileged capture that bypasses Android protections, plaintext originals outside Lockpic, or device loss without a usable backup.
Key erasure on Android's managed runtime is best-effort. Libraries, decoders, video buffers, and the operating system may retain memory copies until reused. Lockpic has automated tests but has not yet received an independent security audit.
Found a security issue?
Send a minimal private report. Never include real patterns, phrases, backups, or media.