How does Delta Chat react to impersonation?

How does the current Delta Chat implementation react to impersonation, i.e. some attacker sending a chat message (email) to a victim with a sender address of someone the victim has already had an encrypted Delta Chat conversation with (which is a quite trivial attack under most circumstances)? Would the victim have a chance to notice? Would the attacker be able to have the (faked) sender’s key replaced on the victim’s Detla Chat installation, thus perform a successful impersonation and cut off the impersonated sender from reading future messages sent to him by the victim?
In more general termns, how do Delta Chat/Autocrypt react to key changes?
All information I got on this subject is back from 2018 and basically stated that Autocrypt does not deal with active attacks. Is this is the current state, and could Delta Chat users thus be easily fooled into thinking they were securely communicating with an existing contact whereas in fact they are doing so with someone completely different?

Starting with version 1.42, Delta Chat offers “guaranteed end-to-end encryption” to protect users against active attacks. This goes beyond Autocrypt by verifying the PGP fingerprints via a QR code scan.

If an attacker uses a different key to sign such a forged message, a warning is shown which links to this FAQ entry: FAQ - Delta Chat


there is also a brand-new blog post that deals with encryption topics: Guaranteed End-to-End encryption and many other good news - Delta Chat

1 Like

So in the scenario outlined above the victim would get a message saying that the contact has “sent a message from another device”? Is there any mention that this is a sign of a potential impersonation attack? If not, do you think that most users would think of and understand this potential and not fall for such an attack?


a dialog shows more information and the text already linked by @missytake above is available directly. the text is available locally, not network required. the text discusses in depth possible scenarios and probabilities and what to do about it.

the “another device” shortcut wording was user tested. it is the best tradeoff wrt probability and giving users without ideas an idea to check if sth. is wrong or not - and that in 5 words or so :slight_smile: and let them really read more :slight_smile:


I’m glad this was added and addresses this very obvious and easy to exploit attack scenario.

1 Like

What do you think about this concerning impersonation?

hm, I’d say the linked scenario doesn’t concern impersonation. Can you clarify how an attacker would impersonate someone?