0

Thunderbird still uses 3DES for SMIME encryption (bug #1167857).

Since 3DES is severely "broken" and uses only 80 bits of security, I would like to tell my Thunderbird, not to use that algorythm any more.

I set the value for security.ssl3.rsa_des_ede3_sha in the config editor in Thunderbird to false but still the algorithm is used for SMIME.

How can I disable 3DES in Thunderbird, so my client uses a secure cipher like AES, camelia, aria or chacha20 for SMIME?

(By the way: also apple-mail still seems to use 3des)

rubo77
  • 2,350
  • 10
  • 26
  • 48

1 Answers1

3

If there would be a way to disable DES3 for this purpose in Thunderbird it would probably be a note on the bug report about it, which isn't. But instead of crying about the insecurity of 3DES let's look at how insecure it is in reality when used together with S/MIME.

The prominent attack against 3DES and other 64-bit block ciphers (like Blowfish) which led to treating these ciphers as insecure is Sweet32. This attack is based on the idea that one can decode part of the traffic provided that the content (plain text) of two blocks is the same or that part of the content is known AND that Ci (derived from IV and previous data in CBC is the same.

This condition is not unlikely with HTTPS traffic because of the properties of the HTTP protocol: a new request and response header will always cause a new encryption block to be started and the request and response will often be the same if the same resource is requested. Thus the weakness in the short block size combined with the properties of HTTP made it practically possible to extracts some secrets (like session cookies) out of the traffic. In experiments this was reached after about 600 GB of traffic but if we deal only with repeating always the same block of data it might be possible with 32 GB. Note that these 600 GB must be done inside the same TLS session, i.e. the same key must be used for all of this traffic.

From this can be seen that this attacks works only if the same key is used for a very large amount of data where a major part of the data repeats again and again so that in a large part of the input data the plain text content of the 64-bit blocks is the same. While such conditions can be created with HTTPS traffic it is highly unlikely to get this condition with mails: While one could imagine mails where the content of a attachments repeats again and again it is unlikely that enough input data for the attack are available since the size of emails is usually only a few MB and not lots of GB as needed for the attack.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • And There is nothing else possible? Maybe create large rainbow tables with all keys or such? I heard, that U can search through all keys with a10000$ hardware – rubo77 May 13 '17 at 06:06
  • @rubo77: '"I've heard..." - please give the source. My guess this was not about 3DES (Triple-DES) but about DES. And the concept of pre-computing with [rainbow tables](https://en.wikipedia.org/wiki/Rainbow_table) might work with hashing but not encryption with larger key sizes like 3DES. You can read more about the security of 3DES [here](https://security.stackexchange.com/questions/146710/is-the-3des-algorithm-secure) or [here](https://en.wikipedia.org/wiki/Triple_DES#Security). – Steffen Ullrich May 13 '17 at 06:12
  • I' ll ask the Person that told this – rubo77 May 13 '17 at 06:20
  • > there is no good reason not to switch to AES. So are you vulnerable RIGHT NOW? Not if you correctly implemented and configured 3DES. Should you be planning your move to AES? Absolutely! It is only matter of time until 3DES is too broken to be considered secure. – rubo77 May 13 '17 at 06:22
  • I also think about future possibilities to decrypt Mails in a few years, that were recorded today – rubo77 May 13 '17 at 06:23
  • @rubo77: I'm not saying that implementing AES would be bad, only that 3DES is still secure enough for this purpose. And as for worrying about the future - the strength is in protecting the unique symmetric key for each message and not so much in the key itself (if the key is strong enough by itself) so you should probably care more about the strength of the public key in the recipients certificate since this one is used to protect the encryption key of the message. – Steffen Ullrich May 13 '17 at 06:31
  • Did you take into account, that the "birthday paradoxon" is applicable here? So the probability that two 64-bit blocks are the same is not zero, thus not negligable. At least It is far below 32GB. `P_n(A') = (2^-64)^n * 2^64!/(2^64-n)!` Maybe someone can calculate `n` here? – rubo77 May 13 '17 at 18:35
  • @rubo77: The Sweet32 attack I've referenced is all about birthday paradoxon. So yes, it is taken into account. But your calculation assumes ECB mode whereas 3DES uses CBC where you also have Ci as input additionally to the plain text. See [Wikipedia](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation) for the difference. – Steffen Ullrich May 13 '17 at 18:47