15

I want to configure my new mail server secure as possible and wondering about the used cipher while connecting to Googles SMTP server.

I'm curious why they prefer the cipher ECDHE-RSA-AES128-GCM-SHA256 before ECDHE-RSA-AES256-GCM-SHA384? Isn't this weaker?

When I test with openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp -cipher ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256 the connection negotiates with cipher ECDHE-RSA-AES128-GCM-SHA256. If I present only cipher ECDHE-RSA-AES256-GCM-SHA384 to the server it uses them.

The most important question: is there a way to force postfix to use only the strongest cipher? If I exclude AES128 via tls_policy it gets even worse!

Ludwig Behm
  • 296
  • 1
  • 2
  • 8
  • If people can't help you here, you should ask your question to the [Cryptography Community,](http://crypto.stackexchange.com/) they might be more able to help you. :) – Yuriko Mar 16 '16 at 14:41
  • 3
    While weaker in theory, it is unbreakable (and therefore plenty strong enough) in practice, and it is significantly faster. In practical terms, you're gaining nothing by forcing AES256. – Xander Mar 16 '16 at 14:44
  • 1
    *"I want to configure my new mail server secure as possible"* - I do strongly recommend *not* to do this, if you want good security (except for case when you're a professional in that area). Rather find some company you trust with your e-mails and from which you know they take security seriously and go with them. It's easier for you and chances are they make a better job at configuring and hardening the server and maybe they also roll some nice encryption plug-ins (like automatic SMIMEA support). Also see [this related question](https://security.stackexchange.com/q/92985/71460) – SEJPM Mar 16 '16 at 21:58
  • 1
    @SEJPM Yes, I'm a network admin, and no, I don't know anyone I trust enough who also supports features like DANE. And yes I'm doing this as a training, too. Sure I can give away the burden of securing my own stuff (and that of my close friends/family) to $company i didn't know, but I couldn't sleep without the paranoia. No it wouldn't be easier. Also thanks for the link and mentioning of SMIMEA! – Ludwig Behm Mar 17 '16 at 09:04
  • You may also want take a look at [Posteo](https://posteo.de/en), who implements many fancy security features. – SEJPM Mar 17 '16 at 10:35
  • ECDHE are ephimeral, are you sure its with the final E? For what i know servers keeping data like mail servers where you need to access to it again use non ephimeral keys since it should be stored in order to decrypt stuff? – Stefano Beltrame Jan 27 '17 at 04:13
  • @StefanoBeltrame This particular key is only relevant to the transport security. Once the message has been delivered, the receiving system is free to re-encrypt the data for storage as it chooses, using any key it chooses. Regardless of whether TLS uses ephemeral or non-ephemeral key exchange, the TLS key will not be reused. – Xander Jan 27 '17 at 15:53

2 Answers2

14

AES-128 is not in practice weaker than AES-256. AES-128 is sufficiently robust that it won't be broken through exhaustive search on the key (see this answer for some details), and an algorithm cannot be "less broken" than "not broken", so there is no additional benefit for security from cranking up the key size to 256 bits.

(There are benefits for marketing, though: longer keys can woo the non-technical minds.)

On the other hand, there is a practical disadvantage to using AES-256: it uses 40% extra CPU when compared to AES-128. This may matter for a server that has very fast network connectivity (say, 10 Gbit optic fibre) or has a feeble CPU. I suspect Google's SMTP server is of the former kind: powerful, but handling lots of incoming data.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 7
    Minor nitpick: AES-128 is not *in practice* weaker than AES-256 *assuming a non-quantum-capable adversary*. At O(2^(n/2)) a quantum computer could, in theory, efficienctly break AES-128 but be foiled by AES-256. Now, what are the odds that your adversary has a quantum computer of sufficient capabilities? Bring out the tin foil hats. Of course, if we are to assume a sufficient-capability quantum computer, RSA is probably the first to fall... – user Mar 16 '16 at 15:09
  • 4
    @MichaelKjörling: note also that there is a difference between "there is a working quantum computer" and "there is a working quantum computer that works at the gigahertz-type of frequency that we now expect from classical computers". There are three successive challenges for QC: assembling enough qubits, preventing decoherence for sufficient time to run the attack, performing enough quantum operations per second for the attack to succeed. Equating quantum-AES-256 with classic-AES-128 means assuming that the 2nd and 3rd challenges are trivial, which seems a bit optimistic to me. – Tom Leek Mar 16 '16 at 15:24
  • 2
    Good point. Just to have it said, I agree with the gist of your answer; at some point, you are looking at diminishing returns, and with properly designed ciphers and implementations, we are probably at that point with 2^128 work factors or thereabouts. – user Mar 16 '16 at 15:28
  • 1
    Similar argument for Chromium: "We intentionally did not implement AES-256-GCM because the security value of the AES-256 is not worth the performance tradeoff." https://bugs.chromium.org/p/chromium/issues/detail?id=442572#c1 – bers Mar 17 '16 at 03:21
  • Great thanks for all the nice replies and links! To be honest, I'm just very skeptical about _the fact_ that _"AES-128 is secure till 2040"_ and PFS will prevent the payload even if the keys are known. Well... I would like to live at least about up to 2070 and expect that at least some of today's encryption will be brute-forced till then. But I would like to make it as hard as possible for them. And especially for your mentioning of the better performance with QC: I would really like to go with ``AES-256`` – Ludwig Behm Mar 17 '16 at 09:25
  • I do not understand the point in "secure till 2040". That's about 21 years from now and the storage capacity for logged traffic is growing. So in 2040 someone who logged enough data will decrypt it. I would like to have an encryption, which holds longer than my lifetime. – allo Dec 13 '18 at 12:28
-1

The correct answer is that there is a timing vulnerability in AES-256 which makes it not weaker as a crypto but weaker as a whole from a risk management point of view.

Benoit Esnard
  • 13,942
  • 7
  • 65
  • 65
thomas
  • 11