Security goals of Delta Chat

1

I’m wondering if someone can help me understand the security goals of Delta Chat a bit better. On the one hand, though opportunistic encryption makes mass surveillance much more difficult, it falls back to insecure, plaintext messages. On the other hand, I can see that the DC project runs needfinding studies with high-risk users like human rights activists and journalists.

When I see posts from users who were surprised to see DC sending plaintext messages (e.g. 1, 2), or who didn’t expect the subject line to leak the contents of messages (e.g. 1, 2) I get a bit worried that this could happen to high-risk users. I know that verified groups avoid these problems, but usable security studies suggest that you can’t always rely on users to know to use such “add-on” security features.

I guess this is a slightly long-winded way of asking who DC is for? Is it for “regular” users who want increased privacy in general, but who don’t have high security needs? Or is it for high-risk users – and if so, why does it allow falling back to insecure chats at all?

I hope this doesn’t come across as too critical – I’m super impressed by DC and the team’s work! But as I’ve been learning more about the project I realized that I didn’t have clarity on this point, and I figured this would be a good place to ask.

1 Like
2

Hey @Tao thanks for asking these questions!

It would be cool to have a Delta Chat security whitepaper … hum … Here are some drafts for parts of chapters from my side, please bear with me if it’s not a full discussion …

Security perspectives in messaging

“security” is a large and emotionally charged topic with many perspectives and approaches. Already with at-risk users we remind ourselves that security is about social user outcomes – do people land in jail, can authorities identify a whole social graph if getting access to a single phone, etc.? This real-world social security can not be obtained magically from a clever algorithm alone. Always, there are threat models and trust choices involved. In many realities, answers to “is using this app secure for you” are highly dependent on your particular situations.

Protection against active attacks

Delta Chat implements “verified groups” protecting against active network attacks, say a compromised messaging provider. In 2017/2018 some of us researched in collaboration with George Danezis (UCL) and Carmela Troncoso and Wouter Lueks (both EPFL) about this topic. Delta Chat implements two of the three protocols as defined from this research setting:

https://countermitm.readthedocs.io/en/latest/new.html

This chapter (of a larger paper) also contains more rationale and security perspective/measurement perspectives.

Implementation security

The core engine of Delta Chat is coded fully in the Rust language, widely hailed for its robustness, efficiency and safety. Delta Chat’s e2e-crypto engine is rPGP which was independently security-reviewed. A new security review, sponsered by the OpenTechFund, is currently starting covering smtp/imap/tls/key handling. The involved codes are liberally open-source licensed and are used in non-Delta Chat projects.

Metadata security

It is hard to protect metadata of “who messages whom” against messaging servers (e-mail, signal, whatsapp, threema, …) and nobody has really solved that, practically. E-mail headers like “To, CC” are TLS-encrypted for most common providers. So the e-mail server operator sees these headers and is instructed by the client to relay a message to recipients. As long as the connection is TLS-encrypted there is no real metadata leakage here. Note that Signal’s sealed sender and recent “encrypted group storage” schemes do not solve the metadata problem: Simple traffic analysis (all messages are passing through a central server!) recovers all the information no matter how much some core-server code tries to hide information from itself. To cut this discussion short: the choice of your messaging providers matters. It is part of your trust and protection model. Luckily, in the e-mail space there is a wider variety of providers to choose from, some principle-based, some money-based or just maintained for the fun of it and your friends. With Delta Chat you have a lot of choices for your trust model, today.

Weakening metadata through “burner accounts”

With May 2020 Delta Chat releases, “Burner Account” support is enabled by default. It enables users to use temporary e-mail accounts which are server-side deleted after a day, week or month. If you form a group of burner-accounts and safely communicate with each other, you can be sure that all traces are gone after a while (except the ones where you take action to share them with another app). Also if a device is taken it reveals a number of random addresses. This is very weak identification because even the messaging provider has no identifying, let alone passport-information about its accounts. The UX flow is that you can share “burner account” QR codes and let friends/folks create accounts based on scanning it. So the provider might know who got the “creation” token but it does not know who got introduced through it.

Weakening metadata through auto-deletion modes

With May 2020 DC releases there are advanced options to “auto-delete” messages on your device or on the e-mail server. This is something you can enable for yourself, it does not affect other chat participants You can be sure that messages are gone after a time without having to hit “emergency buttons” in an already physically threatening situation. The design of these features stems from conversations and analysis of real-world needs and situations. There are rounds of user-testing behind the scenes which we don’t publish in detail to protect participants. DC’s auto-deletion modes operate on the whole account data and are particularly interesting for “mission” phones.

Support for traditional burner-messages, a special form of auto-deletion, will probably land in DC by july 2020 … they protect parts of a chat-group conversation and allow to have “temporary-chats” within a chat without affecting any other chat.

Some notes on perfect forward security (PFS)

Many crypto enthusiasts see “perfect forward security” as the gold standard for end-to-end encryption. Some call it “deletable encryption” as it is about a device forgetting how to decrypt previous network traffic. If someone takes your phone and has previously recorded all your messaging-traffic they can now decrypt the recorded network traffic. “Forward secrecy” prevents that. The “perfect” is just marketing, anyway, and can not be true for any sufficiently complex IT effort :wink:

But even with deletable encryption what if someone takes your phone, what else can they glean? With many PFS-supporting messengers the device-taker gains your social graph through the phone numbers which are tied to passports identification. And they potentially gain all the chat communication that is still on the device – because despite the hero movies … real-life mission co-ordinators in most places recommend to unlock devices if threatened. So “encrypting on disc”, for example, only goes so far here.

Also, often another real-life issue is neglected with PFS: unstable multi-device experiences. If you have multiple devices and mixed offline/online behaviour then PFS-messengers often struggle to provide a stable user experience – note that whatsapp desktop avoids the problem by proxying through the phone always.

Rest assured, there are repeating discussions about PFS and Delta Chat but compared to many other interesting real-life features it’s not top of the prio list with most active DC coders currently.

9 Likes
3

I consider it essential to have a white paper explaining in detail how the entire Delta Chat structure works.

4

Would you consider the recent release of chatmail as the publicly available implementation of DeltaChat’s ‘burner account’ feature that was first proposed in 2020? Or is chatmail something slightly different?

5

It uses the “burner account” or automatic account creation (also called dcaccount: qr codes feature, but that is only a small aspect of it.

The dcaccount qr codes are just a url to a server that gives out email credentials (email + password) when it is contacted (over HTTPS).
We primarily use it currently because we have not implemented a new protocol in the app that knows about the unique registration on login of chatmail yet.
we plan to add a simple button to get a nine.testrun.org account directly in deltachat when setting up a new account, so you can get your friends to try deltachat without persuading them:

  • to use their existing email account (which they likely won’t know the password or don’t want to use for chatting)
  • or making a new account (many people are sick of creating new accounts all the time, especially because they want all kinds of personal data during sign up that is at the very least a pain to type in or a privacy nightmare, depending who you ask).

Chat mails unique signup process is that there isn’t one, you just login and if you are the first you get the account with the credentials you logged in with.

A new qr code format would just contain the email server address and then DC would generate username and password itself (unlike dcaccount:) and login directly without contacting a HTTPS endpoint first. the advantages of that would be:

  • save one roundtrip/http-request → saves time
  • work even when http and https are blocked, as long as imap and smtp work you can get a new account.

Chat mail is that and more, in essence after years of working with the quirks of existing email systems we now also want to explore a best case scenario and develop insights and tips how providers can work better with deltachat.

  • Like the general opinion that email is slow, which we found out does not need to be the case.

Another focus is to not store data forever, auto deletion will probably be enabled by default and email accounts don’t have huge cloud storage, so they will act more like relays that just move the messages and not keep them indefinitely.

1 Like
6

Feel free to start writing one :+1:

7

Is it currently possible to delete a testrun account if it is no longer needed?

8

Better ask this on GitHub - deltachat/chatmail: chatmail service deployment scripts and docs

9

Ok, thanks. :+1:

10

Is it currently possible to delete a testrun account if it is no longer needed?

currently not, however, there is also not much to delete than a random email address that is mostly unattached other data (no phone number, no name, no other address, let alone age or whatnot :slight_smile: )

moreover, after 40 days messages get deleted automatically - but you can prune them before as well, see nine.testrun.org privacy

chatmail is more sth. as a “router”, where everyone can get a slot - but chatmail is not meant to store much data.

this all affects nine.testrun.org privacy only - other chatmap instances can have other rules, incl. options to delete a “slot”

1 Like
11

What’s a high risk user, good Tao? Somebody who tries to hide something? Thieves?

12

People can be in danger from different threats. In some countries religious minorities are hunted by the government or extremist groups for example (happened all over history and still happens unfortunately).
So high risk does not necessary mean people that do bad stuff such as dealing with prohibited objects or engaging in moraly wrong / criminal activity.

Or Russian government hunts people that speak out against the war.

1 Like
13

Thanks for the information. :+1:
According to the website, in addition to random addresses, it is also possible to choose one yourself as long as it is not already in use. Without the ability to delete them, there would be fewer and fewer free addresses over time. For this reason and because I didn’t know that the accounts only use very few resources, I asked.

14

People are hunted because they take part on sensual pleasures and don’t pay it, don’t do tasks but consume. Indeed at high risk, once one likes to take ‘rights’, good master. It’s not a security when giving the feeling of secure, “free” consume, good master Simon.

My person feels more and more insecure in an environment of pseudo-security, yet still thinks good to give some food of thoughts that could be of use for those with little dust on the eyes.

15

I’m not an advocate for the term “Security”, as it is used inflationary to justify a lot of bullshit out our fear (like mass surveillance and “chat control”).

At the same time there are people that are in high risk situations, though those terms are meaningless without context: “secure against what?”, “what kind of risk” and so on.

The fear can be anything, though it does not even need to be related to the “security” measure that is seemingly justifies, sometimes it’s even just enough to say “for your security” without answering the question “security against what?”.

Kinda like the marketing trick of saying “could I please skip the line because I need to copy my documents” in a queue to the copy printer machine. just the trigger word “because” is sufficient to convince people. (The One Word That Drives Senseless and Irrational Behavior)

A talk from someone from digital courage on the topic of “security” (in German, I did not find an translation):

@SamanaJohann so why I reacted to your post in the first place, for me it read like you implied that “high risk” users do not exist or if they do they are bad people / sinners anyway (“Thieves”).
I strongly disagree with this implied subtext (but could be that I misunderstood and interpreted wrong).

Though also I disagree with the fanboys and fangirls of certain messengers that tell every one “my messenger is the most secure ever, if you don’t protect metadata and don’t have plausible deniability you are super insecure” or stuff like that. “Security” does simply not exist without context.

16

Fear and reason has causes, yes. It will not be solved by hiding and running, but by uproot the cause.

Serious: 99% seeking to hide have reasons which are not wrothy to protect, and anonymity is a cheap advertising of consume lure.

It’s not good to suggest security. There is no hide from one’s actions result, of good and bad.

And of course there are no such as fundamental rights at all. That’s just Bauerfängerei or utopian wishes. And of course itjs impossible to abound something that does not exist. It’s likewise inhonest.

Of course there is a security beyond context, but such can not be reached by pseudo security, not even security of Sublime context.

Much better to care about ways and people who use righful means and good ways, ways which are of course not mainstream but not something required to hide.

17

I concur that having overview documentation about security and privacy aspects and architectures and approaches makes sense. Here is my quick attempt to at least link key security and privacy properties and their discussion:

1 Like