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!

  • If people can't help you here, you should ask your question to the Cryptography Community, they might be more able to help you. :)
    – Yuriko
    Mar 16, 2016 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, 2016 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
    – SEJPM
    Mar 16, 2016 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! Mar 17, 2016 at 9:04
  • You may also want take a look at Posteo, who implements many fancy security features.
    – SEJPM
    Mar 17, 2016 at 10:35

2 Answers 2


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.

  • 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, 2016 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, 2016 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, 2016 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." bugs.chromium.org/p/chromium/issues/detail?id=442572#c1
    – bers
    Mar 17, 2016 at 3: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 Mar 17, 2016 at 9:25

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.

  • 3
    O_o Can you explain this in more detail? Any source? Mar 17, 2016 at 7:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .