Hector Martin

There is no magical pixie dust encryption algorithm that will protect your messages in such a way that whatever new version of Signal can access them but no other app or user can (on a desktop). If you have local access it's game over.

How about a non-magical average good encryption scheme where messages stores are encrypted using a password as salt? I don't know why you need to be condescending or exasperated about something as basic as encryption at rest.

What's the point? So you save the messages encrypted, import them, and then what? They're going to be decrypted to be useful, with credentials that any other app can hijack out of the running Signal instance even if they're encrypted "at rest".

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.

And if you're talking about keys stored in memory being useless, you're also sort of implying old fashioned, non-PFS style encryption is useless. Anyway, you're being condescending and it's annoying. Encryption at rest isn't "magic pixie dust" or "throwing encryption at a wall".

You keep trying to straw man me. I never said encryption at rest is useless. I said you need to know your threat model. Encryption at rest is only useful when (attack surface of storage) > (attack surface of active system).

Of course you can concoct artificial scenarios where encryption at rest helps on a desktop, but the benefit is *minimal*, won't stop a dedicated attacker, and thus Signal not encrypting at rest backups on a desktop is not a WTF.