Hector Martin

Adding obscurity and random encryption isn't security, it's security theater. Users need to be aware of the risks of the software they run and how they run it. Adding more encryption when it doesn't help just *makes people think they're secure* when they aren't.

The security model on Android is "other apps cannot access Signal messages". The security model on a desktop is "anything you run can access your Signal messages". This is just how it is, by design. No amount of encryption will fix that. Users just need to be aware.

The point is that in one case, you're defending against a theoretically unlimited nation-state like adversary, and in the other you're defending against a more average attacker who might not even control a keylogger.

If you think it takes a "nation-state like adversary" to pull an encryption key from another process's memory (the best case scehario you can hope to achieve) you haven't seen what kids do to cheat in games these days. Or 15 years ago for that matter.

Methods for defense in depth can seem crude and inelegant to system designers; changing modes of security throughout the work cycle just doesn't feel streamlined. This does not change it's usefulness.

Throwing encryption at a wall to see what sticks isn't "defense in depth". Defense in depth is adding layers of security on a solid foundation. Putting crypto bullet points up on a slide isn't DiD, it's how Sony builds game console security and look how well that worked.

If you encrypt at rest with a password based key (using KDF) that you don't store anywhere, and decrypt only chunks of the data at rest to store in memory, then you are limiting the attack surface. Also, this helps against device theft where they don't conrol your running app

Unless you want to input your password for every single message you view, the key has to be in memory while you use the app, at which point any other process can grab it.