Cache decrypted message to improve user experience (optional)

[cketti]

Decrypting messages can be slow, especially if users need to enter their passphrase first. To improve the user experience we want to add a setting to cache the decrypted content.

As an intermediate step we could store the session key and automatically decrypt the message without any user interaction being required.

[Valodim]

Couple of things that need to be addressed for this to work:

• database structure. I guess the way to go here is to save the decrypted parts in the database like usual, and add a reference in their multipart/encrypted counterparts. There are a lot of pitfalls though, we are probably better off handling this quite explicitly in message loading logic, rather than implicitly e.g. by simply replacing the parts in a database load.
• signature re-verification. Even if we have the decrypted data around, we really shouldn't simply "cache" the signature status. I started some work towards this in https://github.com/open-keychain/open-keychain/pull/1891, returning the message digest so we can re-verify without actually sending the message data. (this should also be helpful for performance in #732, at the moment the entire message will simply be reloaded and decrypted after key download)
• caching policies. Should this feature be optional? Expectations of most users are that encrypted messages must be annoying and unwieldy or they don't "feel safe". But a) if the end point is compromised (root exploit) there is nothing we can do to protect the datananyways, and b) if it isn't, this problem is much better addressed by device encryption. If we decide to cater to the paranoid crowd here, I would still make it opt-out rather than opt-in.

[gdt]

Addressing the paranoid crowd comment, while I see your point about compromised devices, there's a notion of forward secrecy here. Storing decrypted plaintext can be an issue if it leads to a future attacker being able to decrypt it, vs. a future attacker being able to get the key. Perhaps that's too fine a a point.

Also, back to @cketti's original point: is this about the hurdle of the passphrase, or the CPU cost to decrypt? I use OpenPGP on a computer (vs a phone, which I realize is actually a computer) regularly, and with gpg-agent, one types the passphrase relatively infrequently. Then, decrypting on view is fast, but I don't search much. It would be entirely reasonable to keep decrypted mail in RAM for the lifetime of the passphrase being cached in openkeychain, and dropping it if it is too big, and purging it all if openkeychain notifies us of losing the passphrase (cleared, timeout). Or a temporary database keyed with a session key that is lost. That seems to address the speed issues, without really changing the security model.

(I really should use OpenPGP on K-9, but because it's inline only and most of my mail is pgp/mime, I haven't set it up.)

[Valodim]

So what's the attacker you want to protect against? I would argue that there isn't really anything you can do at the app level against an attacker who steals your phone - and that's okay, because it's something that can and should be handled at device level.

[gdt]

The property that matters is that decrypted content should not be written to permanent storage unencrypted, so that if a phone is taken when unkeyed, that plaintext is not available. It's certainly a valid discussion about whether this property should be provided by having the entire ssd encrypted, vs. the OpenPGP passphrase separately. It seems to take extra effort to have an adequately strong whole-device decrypt key while not having to type that to unlock every time (and given video cameras, the unlock PIN can not be considered to remain secure).

[Valodim]

You say it's a "property that matters", but without giving an attack scenario and attacker capabilities you want to protect against, that's just a cargo-cult argument.

Thinking this through in different variations, I always come to the conclusion that if a phone with the secret key on it (even with a passphrase) is taken while unprotected, it is game over no matter what we do. And I really don't want to sacrifice usability if all I get is slightly inconveniencing a potential attacker (and we are talking attackers here who steal your phone to read your email).

The only scenario where opting out of caching decrypted data is an actual increase in security is if the secret key is not stored on the phone itself, but only temporarily available through some channel, e.g. from a Yubikey. So yes, there should be a way to disable this feature.

[Valodim]

Hmm. I just implemented the intermediate step, storing the session key. It works fine, but seeing the decryption routine work without asking for a passphrase like usual does feel a little creepy, even to me...

[vsrinu26f]

:) yes. But this convenience should be an option that can be turned on/off.

Even better if user can choose to add to catch per email first time he decrypts it. :)

Thank you Srinivas

On Jun 17, 2016, at 9:27 AM, Vincent Breitmoser notifications@github.com wrote:

Hmm. I just implemented the intermediate step, storing the session key. It works fine, but seeing the decryption routine work without asking for a passphrase like usual does feel a little creepy, even to me...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[gdt]

I'll try to be more concrete. First, I'm assuming that there is a decent passphrase, and that there is caching of the passphrase similar to gpg-agent.

Then, there's whole-phone encryption, but that seems to commingle decrypt key and unlock code. I've seen reports of people having to unlock devices at customs. In addition, there are backups, which in my view should not include decrypted mail. In general, I am concerned about loss of the device while not keyed with the passphrase.

The real issue is probably a disagreement about which security mechanisms one views as primary and more important/reliable than the others. I think it comes down to you thinking email encryption is lesser than whole-device encryption, and my seeing it as greater. I can certainly see both sides.

[Valodim]

I don't think "decent passphrase" is a reasonable assumption on a mobile device. If the attacker can mount an offline attack against the key, the entropy you can reasonably expect any user to input on a regular basis just isn't enough. For comparison, a typical pwgen-generated password (8 characters, case-sensitive alphanumerical) has maybe 50 bits of entropy - and even that is more complicated than anyone would want to input on a regular basis.

[vsrinu26f]

The beauty of k9 is it gives more control or more options for user to choose and customize.

We should try to give user option to choose caching all session keys and /or

Option to add to cache on decrypting and reading an email. That way I can select my paranoia per email.

Thank you Srinivas

On Jun 20, 2016, at 7:39 AM, Greg Troxel notifications@github.com wrote:

I'll try to be more concrete. First, I'm assuming that there is a decent passphrase, and that there is caching of the passphrase similar to gpg-agent.

Then, there's whole-phone encryption, but that seems to commingle decrypt key and unlock code. I've seen reports of people having to unlock devices at customs. In addition, there are backups, which in my view should not include decrypted mail. In general, I am concerned about loss of the device while not keyed with the passphrase.

The real issue is probably a disagreement about which security mechanisms one views as primary and more important/reliable than the others. I think it comes down to you thinking email encryption is lesser than whole-device encryption, and my seeing it as greater. I can certainly see both sides.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.