(This seems redundant now, that manual key imports will likely be removed)

[aelius]

@link2xt

Delta Chat does not treat the mailbox as an archive

Yes, but the user who uses their existing mailbox (not chatmail) has their own archive, which is an important benefit this model provides. The freedom to literally own your own data, fully independent from deltachat, easy to transform it to whatever format you wish. It is, after all, just text and pgp. Once decrypted, there are no shortage of tools to aid in processing eml. It is quite portable.

It’s also entirely possible to export keys collected by deltachat and import them into a different email client, which will read from the archive. In this way, one does not need to always use the deltachat client - I have on occasion used the mail client aerc in “group chats”, so I can compose lengthy and formatted messages the deltachat interface does not realistically allow for.
Although, as deltachat increasingly encourages chatlike norms (reacts, editing past messages, maximum of 1 quote reply, etc), the general density of information per message is decreased, creating friction with using other clients to access the archive. My hypothetical ideal frontend to deltachat would attempt to keep email social norms part of the experience.

But, as I reflected on in my previous post, I think this not a goal of the project.

If you look at an archive of OpenPGP-encrypted messages, some messages that were secure back then may be insecure now

Good point, I had not considered this… although, I don’t think deltachat does anything about this, either? Other than suggest you might one day discourage the use of non-chatmail mailservers, or drop support for the setting to not delete the mailserver copy.

The primary reason users import the keys is that they have previously used GnuPG or Thunderbird and created a key there

I’m recanting my complaint because if deltachat is not super invested in “email norms” (for lack of a better term), there isn’t really a compelling context in which someone would want to migrate their known key to deltachat.

[bencan]

@link2xt

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.

That’s correct, thanks for pointing this out. I had in mind to export the keys as well as the vcards for all my contacts, although I didn’t mention the vcards above since they weren’t relevant to the discussion. My assumption is that the keys and the vcards would be sufficient for a small backup, and for group chats I’d either need to export the links for group chats in my backup or ask contacts to add me again to the groups when I restore from a backup. However the keys alone are only half a backup, and the vcards alone are only half a backup!

@link2xt

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.

Automatically triggering AEAP is clearly a problem in this case!

If you are moving to identifying contacts primarily by key fingerprint, maybe this is a good time to design for the possiblity of supporting multihoming in the future as suggested here by SoniEx2?

@link2xt

RSA keys without a subkey (which is then used to do both encryption and signing which is generally considered a bad idea

Do you have recommendations where I can read to learn more about this for general interest?

@aelius

Although, as deltachat increasingly encourages chatlike norms (reacts, editing past messages, maximum of 1 quote reply, etc)

I don’t think the maximum of 1 quote for replies is a result of Delta Chat encouraging chatlike norms. There has been some disccusion here about making text selectable in all clients and some discussion here about adding markdown support, so with these features added it should be possible to write replies with multiple quotes, which would be great! (Admittedly the discussion about making the text selectable was started over five years ago, so maybe it’s not a priority feature, but I don’t think this was limited to encourage chatlike norms.)

However I am curious exactly what type of message a recipient using a traditional email client (or an older version of Delta Chat) sees when a message is edited or deleted? This is not explained clearly in the FAQ.

[link2xt]

@aelius

Good point, I had not considered this… although, I don’t think deltachat does anything about this, either?

Delta Chat stores the plaintext and security status (show padlock or not) from the time the message was checked. If the message is “secure” now, it will not become insecure or undecipherable later because some key expired, got revoked, rotated etc. IETF OpenPGP mailing list keeps discussing how to treat hard-revoked/soft-revoked/expired signatures even now. Checking signatures on archived messages is not well-specified.

@bencan

That’s correct, thanks for pointing this out. I had in mind to export the keys as well as the vcards for all my contacts, although I didn’t mention the vcards above since they weren’t relevant to the discussion. My assumption is that the keys and the vcards would be sufficient for a small backup, and for group chats I’d either need to export the links for group chats in my backup or ask contacts to add me again to the groups when I restore from a backup. However the keys alone are only half a backup, and the vcards alone are only half a backup!

You also need to remember which contacts have green checkmark or not because these are the contacts that can add you to groups with green checkmark. As we are going to make encrypted chats to never downgrade to unencrypted chats, maybe we will also relax the requirements for green-checkmarked chats or ideally have a single encrypted chat type, then just backing up the vCards may work. Currently I think it this hand-made backup will not work as expected.

Sidenote: we recently tested Secure Value Recovery in Signal. If you setup a PIN code for SVR and then reinstall Signal, you can enter your PIN and get access to your groups chats and your address book, together with verifications of the contacts. But you get a completely new identity because they key is not backed up. Everyone else will not see you as verified anymore. Maybe this is because they don’t want to trust SVR (which is less secure than your own devices, only protected by PIN codes and relying on “secure enclaves”) with the key. Counterintuitively, your key is the last thing you want to backup: losing your key is better than backing it up insecurely. It’s better if nobody has the key anymore than if you have the key but also an attacker has the key.

@bencan

If you are moving to identifying contacts primarily by key fingerprint, maybe this is a good time to design for the possiblity of supporting multihoming in the future as suggested here by SoniEx2?

Multi-transport is the reason these PGP-contacts are in development.

@bencan

@link2xt

RSA keys without a subkey (which is then used to do both encryption and signing which is generally considered a bad idea

Do you have recommendations where I can read to learn more about this for general interest?

It is a sort of common wisdom:

• encryption - Using the same RSA keypair to sign and encrypt - Cryptography Stack Exchange
• cryptography - Why should one not use the same asymmetric key for encryption as they do for signing? - Information Security Stack Exchange
• cryptography - Is it dangerous to use the same key (RSA) for both encryption (PGP) and authentication (SSH)? - Information Security Stack Exchange

Technically you can do this and there is probably no attack because of padding and the way encryption works in OpenPGP, but it’s much easier to just not reuse the key for different purposes than analyzing what happens if you pass signed message into decryption or encrypted message into signature verification.

[aelius]

@bencan

I don’t think this was limited to encourage chatlike norms

I am not saying there was a formal declaration “chat norms 4 ever!”

The encouragement is implicit in the UX. The UX shapes how the app gets used.

[aelius]

A thought did just occur to me:

While there is the risk that users will bring in old and insecure keys, there’s also a flipside to that.

Should deltachat cease development for whatever reason, it would still perform its function for as long as future keys are still backwards compatible with the internal logic. Which I imagine could be decades.

Without custom key support, deltachat can only remain viable for as long as someone is around to update the key generation function.

Then again, large mail providers will probably decide to close off access to any client not speaking oath3 long before then :v

[link2xt]

@aelius

Should deltachat cease development for whatever reason, it would still perform its function for as long as future keys are still backwards compatible with the internal logic. Which I imagine could be decades.

What are future keys? Current EdDSA+Curve25519 keys are not going to be replaced by anything other than PQC, and PQC requires doing development, not importing the keys.

[aelius]

I forgot that deltachat needs to do the encryption/decryption, whoops. I was thinking about pgp broadly and my wires got crossed.

[link2xt]

One of the reason for not supporting custom keys is to enable transition to PQC keys in the future. If users can have all kinds of keys e.g. primary key that is not allowed to do certification of new subkeys, we may not be able to automatically create a new subkey. There are other problems like the need to somehow transition from v4 to v6 keys, but having custom key structures that we don’t know about further complicates this.

[bencan]

@link2xt

Technically you can do this and there is probably no attack because of padding and the way encryption works in OpenPGP, but it’s much easier to just not reuse the key for different purposes than analyzing what happens if you pass signed message into decryption or encrypted message into signature verification.

Thanks for the insight. I’m not a cryptography expert and lack some of the common wisdom, but it’s always nice to learn more and gain a better understanding!

@aelius

The encouragement is implicit in the UX. The UX shapes how the app gets used.

True. But if there was no chatlike experience, it would not have a broad appeal and less people would use it.

@bencan

However I am curious exactly what type of message a recipient using a traditional email client (or an older version of Delta Chat) sees when a message is edited or deleted? This is not explained clearly in the FAQ.

Does anyone know how edited and deleted messages appear to people using a traditional email client or older version of Delta Chat?

I think it could also be worth explaining this in the FAQ in the section about editing and deleting messages.

[bencan]

@link2xt

One of the reason for not supporting custom keys is to enable transition to PQC keys in the future.

Maybe another potential benefit is you can fit the key in the QR code to immediately establsh guaranteed E2EE?

[link2xt]

@bencan

Maybe another potential benefit is you can fit the key in the QR code to immediately establsh guaranteed E2EE?

The plan is to encrypt the first message with a symmetric key which can be stretched from the “password” in the QR code and will not depend on the public key type: SecureJoin: encrypt `{vc,vg}-request` message · Issue #5182 · chatmail/core · GitHub
PQC keys are larger than current keys and even current keys don’t really fit well into QR codes.

[bencan]

@link2xt

PQC keys are larger than current keys and even current keys don’t really fit well into QR codes.

True, I thought the current keys might just squeeze in, but with PQC keys that’s going to be a lot larger.

@link2xt

The plan is to encrypt the first message with a symmetric key which can be stretched from the “password” in the QR code and will not depend on the public key type:

Sounds good! Clearly it won’t suit every use case (for example when people publicly display their QR code/invitation link on a personal website or social media profile, even though it’s not a “recommended” use case) but it’s better than sending unencrypted messages.

Is the security of the stretched password independent of the length of the first message?

Will the “password” in the QR code just be the 8 byte challenge code or will there be additional bytes added for the password?