I used my normal PGP e-mail key also with Delta Chat, since I want people to be able to compare the fingerprint to my normal e-mails as well. However, as is common for normal e-mail keys, this key expires in a few years. This leaves me antsy since in the DeltaChat UI, it’s not obvious if it’s equipped to handle this situation.
Most importantly, the PGP expiration date doesn’t seem to be shown in File > Settings > Advanced Encryption, of the key currently in use. It doesn’t even seem to be possible to show the key that is currently in use with its fingerprint.
Furthermore, there is no obvious way to swap the secret key in a way where it’s signed with the old one, and distributed to all devices and trusted contacts in a signed verified way such that the key exchange works without everything breaking down. The “Import Secret Keys…” button could in theory do that, but it doesn’t really say if it transitions the keys in any way. Since it doesn’t state that, I’m guessing it doesn’t.
My apologies if this is just me missing something, in which case perhaps this post can inspire some UI clarifications.
Operating System (Linux/Mac/Windows/iOS/Android): Linux
Expected behavior: It’s obvious when a PGP key expires and how to update it with a newer one once the time comes
Actual behavior: It’s neither obvious when a PGP key expires, nor how to upgrade a key without just replacing it without any smooth key transition
Steps to reproduce the problem: 1. Open “File” > “Settings” > “Advanced”, scroll to “Encryption”. Try to find out when your key expires, or what to do once it does.
Unlike some other PGP-incorporating software, Delta Chat does not expose anything about OpenPGP keys to users in the primary user interface. It ties back to various user research/UX findings and follows this design principle: “don’t talk to users about keys”. See also Background — Autocrypt 1.1.0 documentation
Moreover, there currently is no expiry for the default deltachat-generated ED25519 based keys. If you import a key with expiry (through advanced settings) then the result is undefined after expiry – delta chat might still use the key or error out.
It’s likely we go for implementing some form of (probably manually triggered) key-rotation (maybe along the lines you suggest, maybe differently) in 2025 but it’s not super-high on the priority list. So hopefully this comes in time for when your key expires
Where is the discussion about removing support for using your own pgp keys?
I’d like to vote no on that
It ties back to various user research/UX findings and follows this design principle: “don’t talk to users about keys”.
This is well and good, but that doesn’t mean it’s also a good idea to discard your technical audience.
This is one of the more frustrating trends in modern software: reducing all functionality to the least common denominator results in software usable by only the least common denominator- ignoring that this is an abstract concept and not literally representative of the actual audience. Users are not spherical cows in a vacuum!
This philosophy is further detrimental for even the hypothetical least-common-denominator user, as the tendency for modern software to disregard “edge case uses” in pursuit of simplicity ignores the reality that, over a period of years, it’s highly likely most users will find themselves in “the edge case” from time to time. And then what?
I suggest you start a new post to bring it up. I have to admit I’m not necessarily in favor of it either, but it seems to be where the roadmap is currently going.
if you are technical you can still edit your account database yourself or even write a tool to do that.
My Personal opinion:
Using custom keys in possible old/ancient algorithms is nothing that the core team can support with our limited resources - besides supporting old encryption algorithms that are already broken degrade the security guarantees that you can make about delta chat.
In this specific case about a super advanced feature like manual key management: Fork the app and do what you want. you can ask in this forum if you have questions on how to do that or how delta chat works under the hood.
edit your account database yourself or even write a tool to do that.
If it can be done by editing the db, that’s reasonable, although I imagine this will be difficult to propogate the new key to android/iOS clients? And unless there is an “official” respected set of instructions on the wiki or elsewhere, this becomes dicey territory. “it can be hacked in" is not great, there needs to be some notion of stability here (eg code changes that would alter the manual procedure should be considered breaking change via semver)
custom keys in possible old/ancient algorithms
This is a reasonable worry, although the stance could be “only xyz supported” rather than removing the ux altogether.
this specific case about a super advanced feature like manual key management
Something I would like to do soon is get an understanding of how the deltachat devs see their app. The current written information presents a certain impression, but increasingly it appears that you may prefer to see this as a proprietary chat that happens to use email as a backend.
Forking is not an option for iOS users, sadly.
The notion that manual key management is “super advanced” is true in a sense, but falls apart when you consider that there are many programs that attempt to make key management easy for the end user- arguably deltachat is one such program. It’s not necessarily advanced, it’s also a component of being a pgp email client and necessary for users to migrate to/from the dc client.
Which does bring me back to wondering if dc intends to move towards a more proprietary chat system, and for all practical purposes phase out the “email client” aspect.
@aelius Please start a new topic with a description of your workflow, whether you use DC to send/receive encrypted or unencrypted emails, which other clients you interact with and how/when you generate new keys and when you need to import new keys into existing profiles.
I completely agree with this! in a perfect world all the MANY technical and edge-case-users, plus designers etc. would donate time/work and money to Delta Chat and we could have millions of money and work-force to spend in supporting everyone, maybe even with different flavors of apps focused on different audiences and giving support and maintenance to every edge case feature, but sadly in the world we live, Delta Chat is a small project without money from Venture Capital nor big donations or support, and we barely manage to keep alive and kicking by focusing on the more important things that would have the biggest impact
For those of us who aren’t so well informed, what is the nature of the proposed change?
Will it mean that keys can no longer be imported or exported at all?
Or will it continue to allow exporting keys but no longer allow importing keys?
Or will it continue to allow importing and exporting keys, provided imported keys don’t use outdated algorithms?
This approach works well, however I see that the current design already doesn’t talk to users about keys anywhere in the workflow of an “average” user. You can only find it if you are looking for it (in which case you probably have a good reason for that).
Venture Capital would probably ruin it anyway or try to steer it in a bad direction. Funding is important, but I appreciate Delta Chat’s commitment to organic growth and making software that puts users at the center instead of investors!
I agree too!
I found this thread in search after seeing the change log in the latest Delta Chat update which said, “remove dangerous encryption options from Advanced settings”. I’ve been finding that users are growing to want to be more technologically aware especially in terms of self-agency in privacy and security. It’s like how 25 years ago, only a very small number of people knew how to or wanted to use a smartphone that could install apps, edit images, and browse the web, but today everybody knows how to do that. In 2007, the Apple iPhone became popular because it only had 1 button and was perceived as easier than the other smartphones at the time, but today the iPhone is more complicated and hard to use than any Palm, Blackberry, Symbian, or Windows Mobile smartphone was 18 years ago.
THAT BEING SAID… this explanation on Github ( Remove import-key facilities (by file and through incoming Autocrypt Setup Message) · Issue #80 · deltachat/interface) makes much more sense than “remove dangerous options” as that clearly explains why it makes sense to remove them… and that kind of clear wide-open transparency is what normal people are going to be looking for in the future of trustworthy tech. Normal people are getting sick of the manipulative “trust me bro” explanations (and often lies) that we constantly get from big tech corporations and government politicians.
So I vote to please don’t hesitate to give normal users the full explanations. They will appreciate being treated like an equal even if they don’t understand.
I updated the app and now I have an answer to my question. I didn’t realize the change would take place so soon!
I agree completely with @adamzea that users appreciate clear communication from developers.
Not only does the changelog fail to explain the “why”, but unfortunately it also fails to properly explain the “what”. “Remove dangerous encryption options” doesn’t really convey the same thing as “remove ability to import/export keys” or “remove manual PGP key management”. Ideally the changelog should give users a clear idea of the changes and not use confusing euphanisms.
I fully second that. I would also add that I think users deserve fair warning about the removal of longstanding features in the form of clear and timely communication. While I saw a lot of attention given recently to exciting new features like editing messages, as a user I never saw any communication that the longstanding key management feature would be dropped. It seemed to just disappear overnight.
For what it’s worth, I don’t use custom keys, but the key management feature would still be useful to create backups with a small file size, which unfortunately is not possible currently with the standard backup feature, as deleting the (often very large) BLOBDIR directory is not considered a supported use case and is not guaranteed to work. With the removal of the key management feature, I can only hope that the standard backup feature will soon include an “account and contacts only” option in the future.
This is also a good point. Ideally apps will find a good balance between empowering technically inclined users to take more control, and providing a simplified experience for casual users who just want to get things done with default options. I don’t think those goals must necessarily be mutually exclusive.
Oh, that’s a good idea! In the “Export Backup” dialogue, in addition to the info that’s already there explaining the use of the backup function, maybe there could be checkboxes for:
Account login, Autocrypt encryption keys, and contact list. -10kb
One of the things I’ve been “selling” people on about Delta Chat was the fact that you, the individual, can (could) manage the encryption keys yourself as an aspect of trustworthiness and openness. Where-as all of the other messaging apps hide that away from you so you don’t know what’s really going on. With all of the other popular centralized messaging apps, it feels like somebody else owns the keys and you really aren’t in charge of your own communications (because you aren’t).
The exported blob is a Transferable Secret Key, this is all you need to get the key out. public_key is redundant.
Same for importing, you can replace the private_keyandpublic_key in existing profile. This is basically what the key import function did, but it also kept previous key as another row completely invisible anywhere in the UI. Replacing your identity key breaks group membership as your identity will change and you will write into existing chats with a new key which is not expected and usually displays as [The message was sent with non-verified encryption. See 'Info' for more details].
Point taken. Communication got lost a bit – probably including more of Remove import-key facilities (by file and through incoming Autocrypt Setup Message) · Issue #80 · deltachat/interface · GitHub would have made sense, maybe only mentioning it in changelog, not device messages. The points from the issue stand though. You can get the key out, but no key in, anymore. It’s possible that a new transfer protocol that includes also contact’s key etc. arrives in some future. Some of us are going to discuss it at the OpenPGP summit in April with other mail agent implementors. Until then, you can play around with sqlitebrowser as described by link2xt in this thread. For your info, this week where this device info message was drafted, was also the week where this happened: Delta Chat: "Bummer. Last week our OpenTechFund contract was n…" - chaos.social
I think that would be a great idea, simple and intuitive! Perhaps another option, in addition to the current options of “current profile only” and “all profiles”, could be a “select profiles” option.
I like that we can all share our views in this community and always learn from each other.
Speaking of device messages, I find it strange in hindsight that I haven’t seen any new device messages since January, despite the release of major new features like message editing. Is there a bug with device messages or was the team just too busy with everything happening to include new device messages recently?
Yes, the Github issue which explains the change has valid reasoning. While I think that the pitfall of breaking green-checkmarked groups could also be avoided for example by only allowing key imports at account creation (before joining any groups), I understand that the effort to maintain the code for this probably isn’t worth it and can be used better elsewhere.
It will be interesting to see what developments come from the summit regarding key transfer protocols as well as other issues. While I know that it is sometimes considered overrated, I’m sure many people would also be happy to see post quantum encryption on the roadmap.
That is really a bummer! I hope that alternative funding sources become available.
It is possible in the core, but to expose it in the UI during profile creation we need a real usecase. E.g. for bots you can import the key right after creating a profile. It is also possible in deltachat-repl debugging tool. Importing a second key however throws an error now. It was possible to have multiple keys before because nobody thought about it and it remained since initial C implementation, but now I cannot think of a reason why you would want to have a key that is used for decryption but is not visible anywhere in the UI and is never sent to anyone and has unused identity key
Exporting and importing keys does not work as a small backup. If you lose all contacts and their keys you will also not be able to tell which group chats are valid because you have no “verified” contacts to start with. Not to say that you will not be able to see any groups you are in until you receive some message there.
Having read more on the topic (thanks @adamzea for providing a link) -
Please start a new topic with …
Not sure it’s worth litigating.
It’s not about “you broke my workflow”, and it’s not about expecting there is infinite dev time and resources (adb comes off a bit patronizing there).
I think it comes down to this:
I am generally enthusiastic about how deltachat works- where dozens of new chat programs are competing to establish privacy with complex new protocols and new infrastructure, deltachat brings concretely understandable encryption on existing infra: it’s just email, the encryption method is well established. Your chat history is just a set of files that you can transfer to any computer or email provider. It’s so tangible. Understanding how it works doesn’t require reading a whitepaper or technical expertise.
And it already exists! Deltachat’s innovation is to present this in a format more familiar to users of chat (with a fair number of technical optimizations).
But my imagined vision for how this would play out contained some assumptions that I suppose I should drop.
Specifically, I was excited about the idea of making pgp encrypted email more accessible to new users. But over the last few years with the addition of reacts + editing, and removal of custom keys, it seems I was wrong to consider DC as [a modern frontend] / [an onboarding of new users] to an extant ecosystem. DC is instead setting out to create it’s own space.*
Which is fine. I just needed some clarity on this, so that I may set my expectations and stop needlessly objecting to planned features.
*: I understand that some interoperability remains.
If someone has an existing workflow that involves importing the keys into Delta Chat I’m still interested in learning about it. Technically it can even be introduced somewhere in the “advanced options” of “classic e-mail login” screen, but it should not be encouraged. The primary reason users import the keys is that they have previously used GnuPG or Thunderbird and created a key there, so it seems natural that this key now needs to be imported everywhere. In case of Delta Chat importing the same key into multiple profiles is not going to work properly as it already triggers AEAP and we want to move to the contacts being identified primarily by the key fingerprint rather than email address. There are other problems with importing the keys, e.g. users imported the keys which don’t have encryption or signing capability, RSA keys without a subkey (which is then used to do both encryption and signing which is generally considered a bad idea by cryptographers) and large keys with unnecessary information.
Delta Chat does not treat the mailbox as an archive, it uses the inbox as a feed and only processes each message once, archiving the message contents in the local database. You can try to take your message archive and feed it into Delta Chat by copying the messages into the Inbox, but the result will be different, at least because all the information about the QR codes that you scanned is missing. Even outside of Delta Chat archiving your OpenPGP-encrypted emails as a folder of .eml files, especially if the folder is stored on the remote server, is complicated. In Delta Chat if the message was received and evaluated to be encrypted, it gets a padlock icon. If you look at an archive of OpenPGP-encrypted messages, some messages that were secure back then may be insecure now because they use outdated algorithms for signature or the keys have expired, and you might want to delete the encryption keys that are not used anymore: Guidance on End-to-End E-mail Security
