Encryption Details (questions/discussion)

Feature Proposal
1

[ Initial List ]
[ Last Updated Final List ]

I am not a crypto expert but I would say:

It would be much better to have each message individual in size and content.

Example:
You sent one message out (with option send copy to myself ON),
Then the same message is sent twice (one encrypted for you and one for the receiver).

A hacker would have then:
2 Public keys and 2 same messages
I could imagine knowing this, the hacker has more attack vectors to solve the encryption
[Imagine a group of 5, means: 5 public keys and 5 same messages]

That said:
I am pretty sure the security could be improved by making each message individual.

Example:
random block xxx MESSAGE A random block yyy
random block zzz MESSAGE A random block xyz

With that the same MESSAGE A stands between two random blocks (differ in size)
So there a two messages with different content and size (but with the same message A)

With that a hacker has the common problem:
1 Message and 1 Public key.
or according to first example:
2 Public keys and 2 different messages
To say: The attack vector is now smaller.
[And even in the case a hacker got the message A somehow (e.g. screen reader), he will
not get the message as a whole (cause of hidden random blocks) and has still the common problem to find the private key]

What do you think? I think it should be implemented that each message is individual in content and size!

PS.
It is said already, but fits again somehow here too (security aspect: key change):
Please let me export also only the provider login&imap credentials + chat contacts.
So I can easily make a new install with new keys (but with existing credentials and contacts)
[Currently I can export/import: keys and whole backup but not credentials and contacts alone]

PPS.
I also liked the idea/post of encrypted storage database (security aspect: hide credentials, keys and conversation against root apps and admins)

2

No, it’s not. It’s sent only once, but encrypted for both you and the receiver.

In the upcoming version, when you login, if the messages are still on the server, some of your chats and all of your contacts will be restored.

1 Like
3

I am pretty sure that this is not correct. It is needed if you use multiple installs synchron. Therefore it is sent out for every receiver. Have you looked into your imap folder?
Forget maybe the “Sent to yourself” message (by the way: that option alone says it is sent out)
as the question is:
If I sent out a same message A at the same time to different receivers (group). Than sending it out with different size and content (but containing same message A) should be safer against attacks.

That is also not the question here: Cause of intentional key-change.
Therefore still a request: Have an option to export/import (backup) credentials and contacts alone.

1 Like
4

It is correct, the message is sent to your SMTP server once (message + list of recipients via TO, CC, BCC headers).
When you have sent to self (aka. the bcc_self-config option) activated, Your address is added via an Blind copy BCC header.
why this way? to safe traffic. People expect a mobile messenger to don’t use up their data plan, unlimited data plans are not common in most countries yet.

But for further encryption details I’m the wrong person to ask as I didn’t worked on that part of DC yet.
I can imagine that changing content with adding junk data at a random offset could prevent some attacks, but I don’t know about the implementation costs and whether it makes sense in the bigger picture. Also while staying compatible with the existing specs we use like autocrypt, but as autocrypt gets a second version soon it might be something that be considered to add there? IDK…

5

Ok, this might be how it works from my client to my server! (yet wondering how encryption/decryption is done on the clients then if it is not done for each one’s key separate? One same encrypted message or rather single email for all receivers? Can only mean the encrypted single mail has for each receiver somehow an encrypted part (containing the same message A) ???

But for sure the encrypted single mail is then distributed (not to use sent out) to all the receivers mail servers.

So I would say the question still remains (in both cases: distribution and also one mail parted into encrypted chunks somehow so it can be read/decrypted seperately by the clients)

6

I do not agree if you say this safes traffic:

I did only a simple test: writing a same small text message to different amount of users.
And I can see the file size increase with more users.

Better example: One sends out a 1 MB file to a group of 4 members (plus one to itself)

Cause it is said that it is always a single mail for all which is sent out:
But this single mail contains (somehow/probably) the file 5 times encrypted so each can decrypt the message. That means the size of the single mail grows to 5 MB for each user to download instead of 1 MB.

To say: The cost is higher with a single mail for all in opposite to if sent out for each individually.
(The sender has pretty much the same size in both cases, but the receiver has more costs than necessary. Plus dont forget the storage size on the server for each receiver inbox. Especially high-quality videos/audios/images) [Plus even more server load]

And by the way: How is the encrypted single mail decrypted for each? I have only or could see only one single PGP-Block?

I guess you have a voice at autocrypt.org. You are named there.

What I want say:
I hope that DeltaChat or rather the developer/company behind it have the intention to provide or stand for the best possible encryption available, or not? That said means e.g. implement specs as it needs to be done but go beyond if possible (clear: without compromise the specs): e.g. suggested hidden random blocks.

7

as far as I understood it, its symmetric encryption and the key for it is encrypted for everyone separately (maybe adding junk there would be an idea).

Not me personally, but yes our company, https://merlinux.eu takes part in the spec.

Depends on who you ask:

  • Our Cuban users don’t care for encryption at all, they just want small data usage.
  • I assume most users think message delivery is more important than super secure encryption.
  • Yes we do care about encryption, but with our small team, it’s not our main nor only objective right now.
  • Security and Privacy lovers like us would love to have the best possible encryption

I don’t think such a feature will come anytime soon though, it would need to be in the autocrypt spec and other email clients would need to support it too.

But if you think this is a real issue and you are able to show it in an example (showing that is is easier to crack the key when its multiple times encrypted) we need to prioritize it, I guess, but again, I’m not one of our crypto experts).

The essential question here is if:

encryption key of message ==
decrypt(key_for_person_A, private_key_of_person_B) ==
decrypt(key_for_person_B, private_key_of_person_B) ==
decrypt(key_for_person_B, private_key_of_person_B) ==
...

is really easier/quicker to solve/crack than:

decrypt(key_for_person_A, private_key_of_person_B) == message_key + random_junk_1;
decrypt(key_for_person_B, private_key_of_person_B) == message_key + random_junk_2;
decrypt(key_for_person_B, private_key_of_person_B) == message_key + random_junk_2;
...
8

It is quite common that laypeople come up with their own ideas and propositions to improve proven encryption algorithms, so the title and this sentence were already a red flag to me :slight_smile:

Delta Chat uses state of the art encryption that has been tested and proven by security experts for decades. It is not possible to break it with current technology in reasonable time.

Therefore, even the slightly larger attack vector is of no use for attackers. If there was a way to improve the algorithms, it would be included in the standard. That renders any effort to extend the standard on one’s own useless and potentially less secure. You can find more information under those keywords:

3 Likes
9

to

First of all. Thanks for your answers.It seems your are responsible somehow for answering in this forum. But I always have written to all, that means to the public and especially to the whole dev-team (to get the answers)
Yet to say: Your answers have helped me so far. All ok. All is more or less a suggestion or rather a thought which is maybe discussed in your team meetings or not (as with other forum posts).

I dont share this view. Going to the main website it offers me an app like WhatsApp and Telegram which are known to be highly secure apps.
And I also mean its was one if not the only one core-intention of this app by Merlinux GmbH.
Even if someone dont care about encryption etc. the responsibilty is yet there.
(An example would be car development/release and the reposibility of the car company)

Yes, thats the questions. But I am the layperson here (to use mbeko’s words).

I have come close to this here: DC standards

Ok, this is a valid meaning. But the thinking behind is simply spoken similiar to: Distribute the same general-house-key to 5 people is less secure than distribute 5 individual keys. Saying this needs no one to be a crypto-expert. Could be that some poeple distribute their general key. I do not.
Also, why not take laypersons serious and create trust in this SW. E.g. creating a missing entry in the FAQ which tells “simply” how the encryption is done in words understandable for simple users and how one can simply verify it. Other words: Giving users simple inside views of how it works would surely improve the reputation of the SW (and I would not have written this post)

For example missing the answers:

Question What ciphers (e.g. methods, bit-lengths) are used by DC:

  • for the assymetric key encrytion and
  • for the symetric content enryption

( e.g the latest I heard a while ago was:

  • assymetric key at least 4096 bit length, elliptic curves
  • symmetric key at least 256 bit length, double encryption AES-SHA-512

)

[
or this one:

  Why you see only one PGP-Block? 
  (As a PGP Block relates in my opinion to exact one private key)

or maybe the example

encryption key of message ==
decrypt(key_for_person_A, private_key_of_person_B) ==

I myself would have written it like

encryption key of message ==
decrypt(enrypted_key_of_msg_for_person_A, private_key_of_person_A) ==
decrypt(enrypted_key_of_msg_for_person_B, private_key_of_person_B) ==
decrypt(enrypted_key_of_msg_for_person_C, private_key_of_person_C)

]

But ok, I agree for more I should study the spec from autocrypt.org.

Yet, maybe someone can answer me (or rather an always actual FAQ entry) the cipher methods and bit-lengths used in DC (and why there is a single PGP-block instead of a single symetric-encryption-block and why is the symetric key exchanged every time at all as their is only one initial handshake (or is there a hidden handshake and the symetric key changes every message))?

10

The analogy with the same general house key is not correct, neither is it to speak about key distribution here. It’s also not less secure as I explained previously.

Do you see the paradox of you claiming one doesn’t need to be an expert while not being one yourself? :wink:

I don’t understand why you’re implying that this is not the case. You said you’re a layperson regarding cryptology and you’ve received serious replies to your suggestion. In those, you’ve been explained that the software can be trusted because it’s open source and uses standard algorithms proven to be unbreakable.

There is quite an extensive FAQ section on encryption and especially, there is an answer referring to the used standards.

From there, you can read up on the involved technologies, e.g. Wikipedia usually provides generally understandable explanations.

Keep in mind, though, that encryption is anything else but simple and you can’t “simply” verify the security. You have to become an expert and conduct a time-consuming analysis. The simple solution is to trust the experts.

If you’re interested in the background of cryptology explained in an approachable way, I recommend the books by Simon Singh and David Kahn.

The ciphers and their parameters can change, so it’s not reasonable to duplicate the information in the Delta Chat FAQ and risk that it becomes outdated and misleading. Also, the “F” stands for “frequently” and it may well be that your questions don’t come up frequently enough.

As you said, it’s best to read up the details in the linked specifications. Then you can look at the message headers or the source code if needed. I would have to look it up myself to answer you.

You can find more information about the use of symmetric and asymmetric encryption in the Wikipedia page about PGP.

1 Like
11

to

I dont know if you are a crypto expert or not but I have this reply:

I can agree with the topic header as it is maybe not correct to suggest improvements in that area if not an expert. It was originally “Encryption Safety” alone (but has been changed). I would like to change it to “Encryption Details discussion” if I could.

But I totally do not agree with all your other views.
Let me tell why (my point of view):

Do you know what DC has implemented?
A spec and an implementation are two seperated things. You can implement a spec fully or partly or go beyond. E.g WhatsApp (I would say they go beyond):

 Privacy and Security is in our DNA

I dont know what your target is, but your answers have more or less not solved any questions I have. Instead you are saying that I am wrong (might be). I would have appreciated you write then how it is if you know how DC is doing it. That would be a better help.

For sure you will not want me in your crypto-team. This is the right decision.
But for sure I will not buy your crypto-SW. Why?
Cause you will leave your customer alone by saying: Here read this and that than you know it. Sorry (even if you do read it as user you might not know what DC has done concrete as already said).

You can compare the situation with the following:
A seller need not to know all the technical details but should have a technical overview and
know about the features and how it works in general.
And the user is happy with the seller and the product as he gets the info he needs.

In my case: I feel responsible as taking this app to friends, So I am somehow in the situation of the seller. But I am also a user. And I would appreciate if DC shows also reponsibility.

Or does anyone buy a car without comparing features with other cars?
Getting no info or help means : ok, than this car is it not. Red flag to use your words.

E.g again WhatsApp. There are lot of technical reviews and articles about the security. So the information is available. Even the side itself provides a small white paper saying it uses

   Message Key – An 80-byte value that is used to encrypt message
   contents. 32 bytes are used for an AES-256 key, 32 bytes for a  
   HMAC-SHA256 key, and 16 bytes for an IV.

(ok, isnt easy to read too, but is one of the answers I wanted (and still want) to know from DC (not the mention the random IV part (init-vector I believe))

And again: I do user feedback.
The examples I have given are only a big picture for discussion to everyone (I am sure everyone could imagine what is meant, even if the analogy might not totally fit. So I see no paradoxon). Clearly, only experts can give answers or can take it further and might think about or lol.

To say: Making things comparable gives trust. That is the intention.
I “know” about e.g. pEp, Tutanota, Matrix, Signal etc.
But I have to decide between UI (user interface), UX (user experience) but also especially
take care for privacy and security and what infos are available for non-experts.

So these are still my questions:
Hopefully someone can answer me (or rather an always actual FAQ entry) the cipher methods and bit-lengths used in DC (and why there is a single PGP-block (as it relates to exact one private key as far I understand) instead of a single symetric-encrypted-message-block and why is the symetric key exchanged every time at all as their is only one initial handshake (or is there a hidden handshake and the symetric key changes every message))?

Also nice would be what is correct?
Given example

encryption key of message ==
decrypt(key_for_person_A, private_key_of_person_B) ==

I myself would have written it like

encryption key of message ==
decrypt(enrypted_key_of_msg_for_person_A, private_key_of_person_A) ==
12

My explanations don’t seem to get through to you and I find your language and repeated editing confusing, so this is my final effort to clear things up.

Delta Chat is a free/libre and open source application. This means you can look up the implementation and build the app yourself. This also means that none of us is a “customer” in the sense that you use in your examples.

WhatsApp is a proprietary, closed source application. You can’t easily verify that it implements what the company or anybody else claims. You enter an agreement with the company when you use their app and their servers, making you their customer.

4 Likes
13

I changed it in order to avoid confusion. Not sure if “Encryption Details discussion” would be a better title.

You can read the source code then you know exactly how it is done:

Yes I meant that.

Conclusion

I get that you’d like more information in the FAQ: You should open an issue on GitHub - deltachat/deltachat-pages: Delta Chat Website listing all the specs/points that you want to have added to the FAQ about the encryption.
That is valuable feedback, but please leave the “I’m entitled to immediate answers” - tone out of your posts. You don’t pay anyone of us for DeltaChat support, do you? Let’s keep this discussion/conversation cool and civil.

1 Like
14

As conclusion is written I rather dont like to add any more !!

But to my self-defense I have to write some words, but I will hold it short:

First of all:
I never have claimed to be right. I accept free speech and other meanings. I have used or often use the small words “would”, “at least for me”, “in my opinion”, “maybe”, “my point of view”. So everyone is free to share it or not. I stated it as user feedback. I would say this was and is civil.

I never claimed to be entitled for immediate answers or that I am a customer or a sponsor:
Please tell where than I change it if it still possible or change it with the use of admininstrator rights.
To say I have written in all cases “For example (e.g)”. And the examples are used to explain/make the idea/thinking clearer to everyone (hopefully).
Maybe name it showcase or analogy or comparison data.
At least for me examples are useful to get the idea.
Is that not clear: How can I be a customer if its not sold.
Is that not clear: How can you be responsible for something if its free.
That does not mean that you cannot feel responsibility. I do feel it to everyone I suggest this app. E.g. that the password is stored in cleartext and to take care about the install path/location (desktop-version) so no admin can see your password as there is a missing session-login.

Editing posts:
I never changed already posted thoughts.
Yes, I do spelling, quotes, line-breaks and add new thoughts
(if I think it is worth to add or as time passes or have been interrupted but want a quick reply)
But I do this only as long there is no reply.
In my opinion it is more readable to have one post than have “thousand” posts.

And the question I placed to no one specific. If no one knows it than is that so.
(Though asking me if naming the used cipher methods is such a big question)
I clearly stated me as user and non-crypto-expert.
For me this is a real paradoxon to link me to specs and source-code to fnd it out myself.
And as already stated: specs and implementations are two sides of a medal.
I dont want comment: code it yourself

Conclusion: I use all the infos I can get to understand, compare, get a feeling and decide what app I want use. For the bigger player it is easier to find out as there are a lot of technical reviews (from experts to the user). E.g. If I would be alone (God thanks this is not the case) maybe I would take Tutanota as my first choice for privacy/security (but has also flaws, e.g. no chat interface, everyone needs to register, ease-if-use and so on)

To say so far I feel great (even with this topic) with DeltaChat and I dont want forget to say:
Thanks for this app and your great work (this goes also to Autorcrypt).

1 Like
15

I forgot: I want to say thanks also for the work behind of all the 3rd party open source tools which are used in DC.

PS. on my own behalf:
I have written Telegram or WhatsApp are known to be highly secure apps.
But I should have better written: are said to be highly secure.
I will not take the burden to make such a judgement. I am not an expert.
And it was only taken as reference to explain my point of view,
as there a lot of other pure messengers around,
which for sure, all in all, includes also: DeltaChat

-----------------------------------------------------------------------------------------------------------------------------------------

16

The answer to this is, at least for me, clearly:
Threema Messenger [Readable and understandable. See Link on Top, Tab Security and Crypthographic Whitepaper.]
OR
Wire (Personal) Messenger, as its also multi-platform like DC
OR

Maybe you add you into this list.
OR
in this list DeltChat is already included:
https://media.kuketz.de/blog/messenger-matrix/messenger-matrix-en.html
Maybe you add a link to this site on your website.

[
E.g Crpythographic Whitepaper
you see: key lengths, random numbers, padding message, db encryption]

One point I want take out as it was the starting point of this discussion:

Padding
In order to thwart attempts to guess the content of short messages by looking at the amount of data,

]

But I know email-infrastructure is different to a specific messaging infrastructure, and it is nearly impossible to do the same or difficult to compare.

17

Feeling responsible regarding security for myself but especially to users I suggested your app. Therefore I have this list I would like to see in a so called “security” update (hopefully):.

1. at least an encrypted email account password it not whole db (especially on desktop version)
2. default connection method set to “SSL/TLS” instead of “Automatic”
3. missing connection option Authentication method “Encrypted password” (see maybe thunderbird connect options for other methods)
4. choosable install path (desktop version)
5. give password stars shown a fix length regardless of the real length of password
6. profile name “My name” with hint text: “(if set this is transferred in the headers too)”
7. an “Emtpy”-button to empty DeltaChat folder on the server manually (without any logic,
only and only for an existing DeltaChat folder, if it does not exists nothing happens)
8. padding (short) messages with random data
9. Make veryfied contact more visible (see that post)

This is to protect me and maybe others to occassionally or accidentally leak secret informations.

This single post need no answers. Each point which is erased or not implemented would make me feel a bit lesser comfortable regarding security (of the otherwise great app).
But sure anyone can continue with adding points to the list or other questions/discussion regarding encryption/security/privacy.

18
  1. at least an encrypted email account password it not whole db (especially on desktop version)

Isn’t disk encryption sufficient for most use cases? There are plans to implement secure backup transfer, but it will likely be implemented using transport security first.

  1. default connection method set to “SSL/TLS” instead of “Automatic”

Automatic means automatic choose between standard STARTTLS mechanism and non-standard SSL/TLS. Both are equally secure. Delta Chat never resorts to Plain automatically. Setting default to SSL/TLS will only result in Delta Chat failing to autoconfigure servers which only offer STARTTLS.

  1. missing connection option Authentication method “Encrypted password” (see maybe thunderbird connect options for other methods)

“Encrypted password” can mean different things, but usually it refers to legacy methods such as CRAM-MD5 developed before use of TLS became widespread, which require server to store plaintext password. Sending plaintext password over TLS is more secure than these schemes as in this case the server can store only the hashed password and your password cannot be extracted directly from the server database. This is why developers don’t have motivation to implement these mechanisms: Support for SASL authentication with encrypted password · Issue #38 · async-email/async-imap · GitHub
See authentication - Security of email (SMTP/POP) passwords - Information Security Stack Exchange for more.

  1. choosable install path (desktop version)

For Windows there is an experimental portable version on https://get.delta.chat/

  1. an “Emtpy”-button to empty DeltaChat folder on the server manually (without any logic,
    only and only for an existing DeltaChat folder, if it does not exists nothing happens)

There is an option for automatic deletion of messages on the server, you can set it to “at once”. It only deletes messages known to the Delta Chat instance, though.

  1. padding (short) messages with random data

Encryption of the same plaintext twice already results in different ciphertexts, because OpenPGP generates a new symmetric AES key each time, which is in turn encrypted with public keys of recipients. The message itself is then encrypted with AES key, which is unique for each sent message.

2 Likes
19

—

And the main reason is: I feel responsible when suggesting this app to even more non-technical users.
Also on the main website is written “Its like WhatsApp or Telegram”. This could give the expectation to somer users it is automatically secure as these apps more or less claim for itself or at least are well-known (true or false) as one of the most secure messaging apps.
They could think: “Nothing to care about”. But its not.
I cannot say: “Look a safe app!”. Its not, if you dont take care. I also dont want say: “DIY”.
This is also true for point 9: “Make veryfied contact more visible”.

Conclusion (at least for me):
I dont drop any of these points.

20

When STARTTLS option is selected, Delta Chat connects over plain connection and issues STARTTLS command. If the mail server does not switch to TLS after that, the connection is aborted. There is no fallback to the plaintext, you have to select Plain option explicitly for that.

Relevant source code in the core if you want to double-check:

There is no way plain text connection is used if the option is STARTTLS.

Here you can check the list of combinations tried when Automatic is selected, it’s either TLS or STARTTLS, never plain: