Hector Martin

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".

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.

'Chunks' can mean 'your last 5 days of messages'. Scrolling further would require a retype. But even if it is kept in memory, it's still good against device theft.

We already have FDE to protect against device theft. Doing it in the app would require you to log in on every boot. It makes a lot more sense to have FDE for the whole system rather than each app implementing its own thing.

The FDE is 1. optional 2. a single 'gate'. Are you saying (and I don't mean this to be a strawman) that everything on q device should be protected by a single password? In my payment app I have a PIN, in addition to my device unlock pattern. It does add security

Credential minimization is desirable and good security practice, otherwise users just write them down. Sure, if you *really* want an app-level PIN every time you switch to an app you can implement that with crypto, but *nobody* wants that for a messaging app.

I write down my passwords.. encrypted.. in a password manager.. I sure as hell don't want anything sensitive stored in plaintext on my hdd even if the hdd is encrypted!