A usable idea for PGP keys with a passphrase

Right now we have the problem that DeltaChat can not use PGP keys with a passphrase. It’s a good UI decision, because we don’t want users to enter their passphrase every time they want to read or send a chat message. This is a no-go for a messenger.

Many people have pointed out that PGP keys should be protected by device encryption anyway, not by file encryption (what a PGP key passphrase basically is). This is unfortunately not possible with every Android device, especially old ones or with some custom ROMs.

The messenger Briar solves this by having a passphrase encrypt the app database. You type it in once, when you start the app. Then the app is running in the background, passphrase in the RAM, and is able to send and receive messages in a way where the user does not have to enter it again.

Many users, especially if they use the same e-mail address with DeltaChat and for “normal” mail, too, have an old PGP key with a passphrase. They also don’t want to get rid of it. I personally have 2 PGP keys because of that, and sometimes end up with unreadable messages if I don’t have my second device at hand. It also leads to confusion with more experienced PGP users sometimes.

If we would use the PGP key passphrase to encrypt the deltachat database though, we could kill two birds with one stone:

  1. Protect our database while the device is turned off (useful, e.g. for the attack model “police confiscates unencrypted phone and extracts storage”)
  2. Being able to import PGP keys with a passphrase, e.g. per Autocrypt Setup Message (which is buggy af right now, especially from Enigmail).
  3. Keeping our user-friendly way of readable messages. They may even feel more secure when they have to enter a passphrase at device startup (I do with Briar).

What do you think?


Maybe there are two things to consider separately:

  1. importing a passphrase-protected key
  2. encrypting DeltaChat’s database with a passphrase

I don’t think that mixing the two is helpful – latest when you import a second PGP key with a passphrase it poses problems. For 2. we could aim to use sqlcipher instead of sqlite.

I agree, they don’t have to be tied.

Nonetheless, I would say that importing a passphrase-protected PGP key into the database should only be possible if the feature to protect your app with a passphrase is easily available. It should be recommended to protect the app with a passphrase when you try to import a PGP key with a passphrase. So we’d need to implement the sqlcipher feature first.

Afterwards we could remove the passphrase from passphrase-protected keys at the import with clean conscience. Better forget them at all, so there is no passphrase laying around if the attacker manages to bruteforce the app passphrase.

I suggest a different approach to make it possible to use password-protected keys also. If Delta Chat would have a password manager (e.g. like Thunderbird) key-passphrases could be protected by storing them on the device with symmetric encryption using a master password. This master password would have to be entered only once at startup and held in memory only.

To keep it as simple as possible for normal users enabling the password manager could be placed in the expert settings.

By the way this approach could protect the credentials for IMAP and SMTP also.

Why does it need to be a whole password manager for like 3 passwords?
Whats against encrypting the whole database?

Encrypting the private key with a different pass phrase might still be a good idea.

My intention is to suggest something which could be realized without much changes in the near future. If Delta Chat would get an encrypted database this would be much better.

Maybe the term password manager is a little bit misleading. What I have in mind is the functionality, that the key-passphrases of all imported keys are protected by a single master password. So maybe keystore or digital wallet is the better term.

1 Like

Encrypting the whole database could also help a bit with Provide messures for the "device lost"-case .
We could also let the user decide if the want to have:

  • Unencrypted database and no Password
  • Encrypted database with password
    • One time startup
    • Each time when accessing the app like an app password (but that would either break the notifications or need to have the database still opened in the background as with One time startup)

That’d be a good optional feature… Many would be satisfied with standard autocrypt crypto.

1 Like

Sorry to resurrect an old thread.
While I agree with the sentiment of keeping the barrier of entry low and not overwhelm users who doesn’t want to invest time with talk about keys and such, I already have keys I would like to use.
This is mainly because those I communicate with know who I am and has already verified my keys. I won’t be able to convince them to trust an auto-generated key.
Setting an empty passphrase is not an acceptable solution for me sadly.
While the “best” solution in my book would be to optionally integrate with the keychains that’s present in every DE (even windows) on the desktop side and openkeychain on Android I can see that short term that isn’t going to happen.

Is there work ongoing on getting keys with passphrases working?

Regarding the suggestion to store things in RAM (master-secret or per-key secret or app-db-decryption secret), please don’t forget that both Android and Apple ecosystems kill the app many times. It’s getting increasingly hard to have a longer running process going in RAM, see https://dontkillmyapp.com/ for how this is not just an issue for us but also for alarm clocks and many other things.

Hm, how does Briar deal with this?

briar does not exist on ios.

on android, they will probably have the same problems, esp. on newer systems - background may or may not work, depending on lots of different settings the user has to tweak - if that is possible at all.

I also wish, I could use existing PGP keys with passphrases. I would like my peers to be able to use the same key they already trust with the same e-mail alias, to respond to my Delta Chat messages. Also I would like to keep the number of keys I have to manage to a minimum.

I do not like the idea to remove the passphrase from a PGP key and distribute that to potentially several devices with more or less trustworthy (multi-user) operating systems.

BTW: Threema uses a notification in Android to keep the unlocked master key in RAM. The master key is used in the Android version of Threema to encrypt the ID’s private key. They are going to publish their code “within the nexts months”.

I was referred to this topic as I stumbled naively into it via #1941 not realizing that the lack of passphrase support could even be remotely considered as tolerable for a GPG based tool.

I realize this is flogging a dead topic, I’m gonna anyway; sorry.

First, if one runs into the “no support for encrypted private keys” problem, the first advice given in the forums is to remove passphrase protection and try again. Please, please never ever suggest that. You WILL get people killed. Seriously. Dead. There are parts of the world where journalists and activists work whose primary profession is operating in democracy challenged environments, not mastering cryptography, but for whom GPG has been and remains a key tool in the fight for freedom.

It is very reasonable to assume, indeed inevitable, that years or even decades of correspondence of such operators is already in the hands of their adversaries and would be used against them and used to unmask their networks if that correspondence could be decrypted. It is important to remember many of these people are not cryptographers, they’re activists who may not fully understand the implications of “removing the passphrase” and be confused by the apparent cryptographic protection of the PIN array for in-transit security and be unaware that this process leaves their keys unencrypted at rest on a trivially compromised device.

Please ensure that the advice for people with GPG keys protected with a passphrase going forward is something along the lines of

"DO NOT REMOVE PASSPHRASE ENCRYPTION OF YOUR PRIMARY KEY, EVER. If you have cause to encrypt your primary key with a passphrase, it is not compatible with Delta Chat’s security model. Create a new key for delta chat alone. Understand that this key is stored in clear text on all devices with delta chat clients and is trivially recoverable by malware, thieves who may steal your device, someone attempting data recovery on a “wiped device” after sale, an “evil maid” who gains even brief access to your device, and certainly by any state level actor who might confiscate your device. If you lose, temporarily lose control of, or sell your device revoke the key you used on the device and start over. All communications encrypted by the compromised key will be available to anyone with access to both the revoked key and that data. Your data is no more secure than your physical control of your device.

“Delta Chat is considering how to implement robust key protection while simultaneously affording a similar degree of ease of use to other chat clients, but this is not implemented yet. Until it is, Delta Chat’s protection should be considered as in-transit only (as the data moves from device to device) and as having no meaningful value in protecting data at rest (as stored on your device).”

This is the age-old problem of “chose one: secure or simple.” I really like the delta-chat model; I strongly believe in leveraging existing self-hosted (or company hosted) mail server infrastructure as both sufficient and robust for other client-server modalities than traditional email and love how delta chat has implemented this. Cryptographic support could have taken many routes too, and leveraging (and possibly extending) GPG is, to my mind, the best method of doing so.

Here’s what I’d recommend: support passphrase protected keys. Make it clear in the UI that if you generate a key with delta chat, it will not be protected, a warning that users should be familiar with for all sorts of services including password managers. Let users choose between security and convenience. Most will choose the latter, but some require the former. Don’t hang the former out to dry. Delta Chat doesn’t, to my mind, need to have a provision for encrypting keys, but it should use them as gracefully as possible, albeit intrinsically thus requiring entry of a long passphrase on a device without a keyboard.

If a user imports an unencrypted key via the autocrypt setup message or via import, the user should be warned that the key is not encrypted and will be stored in plain text on the device. Understand this is an increased security risk compared to storing the key unencrypted on a laptop as mobile devices are fundamentally ephemeral possessions. This is very important as without this warning there will be users who rely on GPG to protect current and historical communications and eventually one will not realize the gaping security hole they created by importing their key into delta chat on a mobile device and some of them will, eventually, be killed as a consequence. Seriously, literally tortured to death because they didn’t understand the consequences. The responsibility for such a catastrophe should be terrifying. Please take it seriously.

If a user imports a passphrase encrypted key and passphrase protection is not implemented in delta chat, the message currently is completely unhelpful and misleading: “Bad setup code. Please Try again.” is unhelpful and unrelated to the actual problem. I would advise that if a user imports a passphrase encrypted key before Delta Chat adds a “enter passphrase to unlock your key into ram for a short window” dialog, it may be useful to offer a more helpful message like:

“This key is encrypted by a passphrase. Delta chat has chosen as a design philosophy convenience over security and does not support passphrase protected keys. You may create a new key within Delta Chat for use with delta chat and autocrypt. Remember to revoke your delta chat key if you lose control of your device at all, ever. All messages that have been encrypted with a compromised key can be read by any adversary having both the key and the messages and both are easily recoverable from this device unless it is physically permanently destroyed.”

I’d suggest a preferential UX would be to accept passphrase protected keys and assume they are passphrase protected for a reason and treat them as live munitions. Only store them in RAM, do not write to flash, allow the user to request a scheduled time out (10 minutes, an hour, a day, etc.) and to request deletion if the device locks. If the OS kicks the passphrase out of RAM, the user has to reenter it. Best effort should be made to minimize the hassle this represents, but if the user has chosen to encrypt their key with a passphrase, they’ve already chosen security over convenience and it seems a little weird that Delta Chat wouldn’t respect that decision and provide optimal compatibility with it.

The user story of the casual user considering delta-chat a less metadata leaking alternative to centrally hosted chat services and that implements robust E2E encryption comparable to other chat clients is not likely to have a passphrase encrypted GPG key they want to use and so supporting those who do actually need robust security, even at the cost of some convenience, is a completely parallel and different user model set and specifically to support those who can live with the hassle of re-entering passphrases as needed to maintain better opsec.

My concern, TL:DR, is that by implementing GPG it is tempting to think of Delta Chat as providing similar levels of security at rest as the vast majority of GPG implementations to date and it does not do so which creates a grave risk of deadly misunderstanding. I’m also frankly horrified by the advice that the way to solve the lack of support for encrypted GPG keys is to remove encryption. Do not ever do that. Do not ever advise anyone to do that. Someone will die because of that advice and in a particularly nasty way that hurts the whole time they’re dying.

1 Like

Unhelpful error message should be treated as a bug indeed. Detecting passphrase-protected keys and telling they are not supported, then suggesting to create a separate key for Delta Chat and warning against decrypting primary long-term key is way better than current error message.

PGP experts may create an unencrypted subkey specifically for Delta Chat, but it is not always the best option. A new completely detached identity may be better for security.

1 Like

@link2xt - The unencrypted subkey option didn’t occur to me, good thought!. There are, I’m sure, use cases where that makes sense.

I come to DC as a long time user of PGP and while GPG users are a tiny part of the digital herd, it is likely that DC’s (brilliant IMHO) use of GPG keys will win favor with crypto enthusiasts. I appreciate an emphasis on ease of use - GPG remains absolutely is too much hassle for the vast, vast majority of users. The autocrypt model is a really solid balance of security vs. convenience that makes GPG accessible and can help make encrypted email a norm rather than an exception - that’s great, no question.

I’d argue that it is possible to support those that have already made a decision to tolerate inconvenience for greater security and integrate them into DC - and that this is a wise strategic decision as security conscious users are likely to preferentially consider DC over metadata snarfing, trust-us “crypto (ish) chat” alternatives. Supporting GPG lights the beacons of Gondor and that sound is the shuffle of all those with framed, Phil signed 1991 floppies of PGP coming to the yard.

There’s no need to afford creation of encrypted keys within DC. But if a user has created an encrypted key elsewhere and wants to use it with DC, it just seems polite and fair to trust they have a reason for doing so and fully embrace that use case as model users of DC. Import the encrypted key, ask for the passphrase, keep it in memory as long as the OS allows, do not write to storage, if the unencrypted key has been dumped out of RAM, ask for the passphrase again. Most people using DC or autocrypt will never see this and never have to deal with the hassle of dooting through a passphrase before reading a message. Those that do need it will very much appreciate being able to.

why not allow the user to encrypt the sql database with a password, sqlcipher can do this.
this would be only an option for advanced users.

what is the problem to optionaly encrypt the database like with Briar ?

This is more difficult than just replacing SQLite with SQLCipher, because Delta Chat does not store everything in the database. Media files, queued outgoing messages etc. are stored outside the database as separate files. Storing them all within the database will make UI development much more difficult as typical Android, iOS, Electron, Qt and Gtk+ (GStreamer) widgets can display images and play media files with a given file:// URL but have no easy way to play the media from encrypted database, so you need to temporarily extract them into unencrypted files anyway. This gives you incomplete protection but makes development much more difficult for all platforms. A proper solution is to use filesystem encryption provided by your operating system, which is more performant and less error-prone as you can’t accidentally leak unencrypted files into swap, leave them on the disk and so on.

UPD: Delta Chat now uses SQLCipher and there is an experimental option to enable encryption, but blobs are not encrypted yet.