ONYX v1.5-beta: Emergency PIN with a full decoy environment
Released v1.5-beta of ONYX, and one of the things we added is Emergency PIN support.
A secondary PIN opens a completely separate decoy environment instead of your real account. You configure what’s in it — chats, avatars, display names — so it looks like a normal, lived-in account. There’s no visual indicator that it’s a decoy.
The use case is straightforward: situations where you’re pressured into unlocking your messenger. The Emergency PIN is kept entirely separate from your main PIN and can be changed at any time.
- GitHub: https://github.com/wardcore-dev/onyx/releases/tag/v1.5-beta
- Website: https://onyx.wardcore.com/
Happy to answer questions.


So, 1 encrypted file, that can be decrypted with two different keys? How does that work?
The lack of response is clear. You don’t know how it actually works, because you’ve just been asking the robot to do it. That is unacceptable for something you are pitching as private and secure.
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.