Hello 
,
emails between DC users are encrypted. However, the name of the DC profile is currently sent in plain text. I’m wondering if it would make sense to move it to the encrypted part of the mail? This would at least prevent a potential attacker from drawing any conclusions about the real people based on carelessly chosen names. 
2 Likes
Totally agree, to me it seems like an oversight that the profile name is left unencrypted. I’m actually surprised this issue wasn’t raised when ETH audited SecureJoin.
And for clarity (question for the developers): if you set the display name for a contact, does that stay local to your own device? Or will it be sent to your email server (e.g. to sync with a second device) and if so is that sent encrypted or unencrypted?
In this case, DC sends an encrypted email to itself to synchronize multiple devices. The names are not synchronized by a server, but by the app itself. The server only sees encrypted emails.
P.S. I am not a developer.
1 Like
Thanks for the answer. And do you know about profile pictures, if they are sent encrypted or not?
The avatar is sent as a Base64 code in the email header.
Unfortunately, I don’t know whether the avatar will be encrypted beforehand.
the avatar is in the “inner mime header”, that gets encrypted eg. in “guaranteed end-to-end encrypted chats”, similar to text and attachments
2 Likes
Will profile names be encrypted in future releases?
Also, I have noticed that even with guaranteed end-to-end encrypted chats, any text which is sent before the handshake has completed is not encrypted. So if the avatar is sent immediately when establishing contact then it’s probably not going to be encrypted the first time it’s sent, right? (Because the avatar will be sent before the encryption handshake completes.)
yeah, this is a longer standing issue, this will be improved in 1.46, see feat: Make one-to-one chats read-only the first seconds of a SecureJoin (#5512) by iequidoo · Pull Request #5550 · deltachat/deltachat-core-rust · GitHub
this will be improved in 1.46 as well: fix: Don't send selfavatar in SecureJoin messages before contact verification (#5354) by iequidoo · Pull Request #5363 · deltachat/deltachat-core-rust · GitHub
for profile names, for sure, this is on the radar of devs as well.
2 Likes
There’s even a PR implementing this: feat: put display names in encrypted headers (#5166) by Septias · Pull Request #5183 · deltachat/deltachat-core-rust · GitHub. But it is still unmerged because of issues with compatibility with other MUAs like Thunderbird, it doesn’t show the display name if it is present only in encrypted headers. For me it’s minor and personally i’d prefer to remove the diplay name from unencrypted headers (and create an issue in the TB bugtracker). But it was suggested also to do that only for verified chats to preserve compatibility with other MUAs, maybe we should go this way for now. Anyway i think we should prioritise this PR to get it merged already.
3 Likes
It’s great to know that there are some fixes in the pipeline for these issues! These are some important fixes in my opinion. Delta Chat keeps getting better and better!
However maybe I am missing something but the title of Pull Request #5550 suggests that the fix relies on timing (“the first few seconds”), but in order to be reliable, the fix should not rely on assumptions about how long the SecureJoin takes.
if what you are suggesting is to make the chat read-only permanently, I don’t think that is a good idea, in fact I don’t like at all the current approach, it just make some noise for some seconds, if the secure join happens faster there was no need for the disabling of input field, if you want you can always wait for the process to complete and then send messages, but if it takes several minutes you might want to just start sending messages without waiting, this, however, will fail if the account is a chatmail account
1 Like
What I’m suggesting is that the chat should be read-only until the SecureJoin handshake completes, if it happens faster then you should be able to send messages immediately (although I don’t find waiting a few seconds to be so inconvenient, after all it’s only once for each contact) and if the SecureJoin takes longer then you should have to wait longer. I think it is a fair expectation that if you scan a contact’s QR code, you should have guaranteed encryption, and simply making the chat read-only for a few seconds isn’t sufficient, since there is no guarantee that the SecureJoin will complete in that amount of time.
I’m fine with having the option to send unencrypted messages if you’re impatient waiting for the SecureJoin to complete, but in this case I think the user should be shown an appropriate warning message and asked to confirm that they want to send an unencrypted message, otherwise it’s way too easy to accidentally send unencrypted messages thinking they are encrypted.
Another possibility would be to disable the send button rather than the input field so that you could start writing a message immediately but only send it once the SecureJoin completes, or leave both the input field and send button enabled but instead of sending immediately, queue the messages for sending as soon as the SecureJoin completes.
What I’m suggesting is that the chat should be read-only until the SecureJoin handshake completes, if it happens faster then you should be able to send messages immediately
Maybe it’s not clear from the PR title, but it’s what is done actually.
if the SecureJoin takes longer then you should have to wait longer.
As @adbenitez said before, it’s not a good idea to make the chat read-only permanently if smth goes wrong. Sometimes it’s better to be able to communicate even w/o encryption than not be able at all. If the SecureJoin hasn’t finished in these several seconds, Delta Chat adds a warning that messages will be sent unencrypted, i think it’s fair enough. If the SecureJoin finishes later, another system message telling about that is added, and the green checkmark as well.
I think the user should be shown an appropriate warning message and asked to confirm that they want to send an unencrypted message, otherwise it’s way too easy to accidentally send unencrypted messages thinking they are encrypted.
Another possibility would be to disable the send button rather than the input field so that you could start writing a message immediately but only send it once the SecureJoin completes, or leave both the input field and send button enabled but instead of sending immediately, queue the messages for sending as soon as the SecureJoin completes.
Wrt such a confirmation from the user and other “interactive” approaches, there were ideas about that but unfortunately we haven’t had enough resources to implement this in all the UIs, so we’ve limited this feature to changes in the core lib and only the warning was added.
Thanks for the clarifications.
It seems to me that another possible solution to entirely avoid this problem would be simply to include the entire encryption key in the QR code. I’m sure there’s rationale for the current way of doing things using SecureJoin, but I can’t seem to find it at the moment looking in places like the Delta Chat FAQ.
A related question about the profile names: are group names treated the same as profile names (so currently unencrypted)?
With edd25519 keys we could try to include the key but it would make scanning cumbersome and as invite link it would be pretty unwieldy. There also RSA keys where it wouldn’t work so it would not be consistently possible. And our general approach is that if we have to implement a fallback anyway, then we rather try to see if we can get away with only implementing the fallback.
feat: Protect From name for verified chats and To names for encrypted chats (#5166) by Septias · Pull Request #5183 · deltachat/deltachat-core-rust · GitHub is merged, so the profile name will be encrypted, but only for verified chats to preserve compatibility with Thunderbird/K-9/etc. But “To” names will be always encrypted in encrypted messages as this is less critical for compatibility.
A related question about the profile names: are group names treated the same as profile names (so currently unencrypted)?
Unlike profile names, group names are always protected (i.e. opportunistically encrypted) already now. The same is true for the “Subject” header.
2 Likes
Thanks @hpk and @iequidoo for your answers and for explaining the fallback design philosophy used by Delta Chat.
It’s good to know that the group names are encrypted and that profile names will soon be encrypted, presumably in the next release.
It seems I underestimated how many bits can be reliably scanned in the QR code, I didn’t fully consider the RSA use case, and you’re right about the invite link becoming unwieldy. (By the way, what does Delta Chat use by default, if you don’t import your own key? Is it edd25519?)
Different people have different threat models. Some people prefer convenience while others prioritize security, so one compromise that comes to mind, which seems simple and practical to me, is to let users with high threat models select “prioritize encryption” in the settings. This preference can then be conveyed in the QR code with a single bit, so that whoever scans a QR code with this bit set is forced to wait for the SecureJoin to complete before sending messages, but allowed to send messages sooner if this bit is not set, therefore respecting the threat model of the contact. Would this be a good idea?
Another idea, but probably more complicated, would be to generate an edd25519 key for every user and send this with the QR code. If the SecureJoin takes too long, use the edd25519 key from the QR code to encrypt messages, and once the SecureJoin completes switch to using the RSA key or whichever key the user selected for themself.
Yes, by default Delta Chat generates an edd25519 key (it uses GitHub - rpgp/rpgp: OpenPGP implemented in pure Rust, permissively licensed btw). As to generating additional keys, we need to be careful to not cause more confusion for those people who try to manually manage keys. We are also slowly starting to consider how to move to OpenPGP V6 keys (see rpgp/docs/FAQ.md at master · rpgp/rpgp · GitHub for what rpgp devs are up, who are also involved with DC core development partially) and that would probably be a good time to consider such “second keys” and then see if they can be used in QR-codes/invite links. This will all take a while – and crypto-things should not be rushed anyway, as we prefer reliability and stability and avoidance of what is known in the matrix world as “UTDs” – “unable to decrypt” issues which Delta Chat users only rarely encounter these days and we’d like to keep it at that 
Thanks @hpk for the information and the update about moving to OpenPGP V6 keys. You’re quite right that key management needs to be considered carefully and I agree that crypto-things should not be rushed! (And therefore I find it’s good to start these conversations early, so there’s plenty of time to consider new ideas.)