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.