this post was submitted on 16 May 2026
25 points (96.3% liked)
Privacy
10671 readers
27 users here now
A community for Lemmy users interested in privacy
Rules:
- Be civil
- No spam posting
- Keep posts on-topic
- No trolling
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
No, it's not one file with two decryption keys — you've got the architecture slightly wrong. There's one storage, encrypted with AES-256-GCM. The PIN doesn't decrypt the file — it's verified at the application level. If the real PIN matches, the real environment loads. If the decoy PIN matches, the decoy environment loads with its own data, stored in the same storage under separate keys. Two layers of data in one container, not two containers with different keys.
Where does the first decryption key come from? Does the user supply a decryption key first, and then supplies a pin? Verifying the pin at the application level means that once its decrypted, the attacker doesn't need the pin at all, they can just read the decrypted data directly.
I'm fairly sure you are just sending these comments directly to your LLM.
On mobile the key comes from the platform keychain — tied to device unlock, not the app. On desktop it's machine-derived. The decoy PIN threat model is coercion — someone watching you unlock. If an attacker already has filesystem access, you've got bigger problems than the PIN.
Machine derived decryption key is basically the same as unencrypted.
Android story is better, but you effectively hold a backdoor. You can push an update that defeats the decryption without any user interaction.
Ideally, decryption should involve the user inputting a pin or password.
Yeah, you're right. I'll fix this in the next update.