2
$\begingroup$

when you look at the encryption websites use you will see that there is alot of diversity, some use 256 bit keys some do not, some use DHE-RSA some ECDHE some use sha 256 some sha1, but my question is, what would currently make the strongest https connection in terms of asymmetric symmetric and hashing algorithms used.(I do understand that there might not really be an overall "strongest" one and that some schemes a better in different situations)

$\endgroup$
5
  • 1
    $\begingroup$ It depends on the the TLS version. $\endgroup$
    – Artjom B.
    Jun 15 '16 at 21:29
  • $\begingroup$ Say tls 1.2, since that is the most secure one for what i know. $\endgroup$
    – blacklight
    Jun 15 '16 at 21:30
  • $\begingroup$ Are you asking about theoretically achievable security? How do you want potential side-channel attacks to be weighted in? What is the set from which cipher suites can be selected (all standardized?)? (As of now, an appropriate P-384 with TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA284 is the "best" somewhat widely supported but will lock out FF users) $\endgroup$
    – SEJPM
    Jun 15 '16 at 21:31
  • $\begingroup$ I indeed focus on theoretical achieveable security, all standardized ciphers may be used, and as far as side channel attacks go, i would like the one which would overall be most resiliant against them(if something like that exists ofcourse) $\endgroup$
    – blacklight
    Jun 15 '16 at 21:35
  • $\begingroup$ This might sound stupid, but wouldn't sha512 be safer? (Please correct me if im wrong) $\endgroup$
    – blacklight
    Jun 15 '16 at 21:40
4
$\begingroup$

The cipher suite with the best theoretical security for TLS (v1.2) right now is clearly:

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 with P-521
as the associated curve for the certificate and the key-exchange.
The arguments are simple:

  • ECDHE and ECDSA with P-521 both provide 256-bit security against forgery / key recovery attacks
  • AES-256 is the strongest possible AES instance you can get
  • CBC is the most resilient mode to IV-reuse (you only learn whether two messages share a common prefix)
  • SHA-384 implies use of HMAC-SHA-384 as the MAC which has a much higher "bit-length-protection" against forgeries than, say GCM

The arguments against it are clear as well:

  • The support situation is probably horrible, because P-521 isn't exactly the most wide-spread supported curve as is probably the ECDSA-CBC-SHA2 combination
  • This suite is prone to many (side-channel / padding oracle) attacks on CBC and authenticate-then-encrypt from the past

Note well: Because of these attacks I strongly recommend against using any CBC based cipher suite.

The cipher suite with the best practical security (and somewhat decent support) for TLS (v1.2) right now is clearly:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 with P-384
Downgrade to TLS_ECDHE_WITH_AES_128_GCM_SHA256 with P-256 / P-384 for more supported systems (such as Firefox)

  • ECDHE and ECDSA with P-384 both provide 192-bit security against forgery / key recovery attacks, which is on the edge of "physically infeasible" and will likely remain unbroken until the rise of quantum computers, the support is really good here, because P-384 is part of NSA's Suite B and many people implemented it because of that
  • AES-256 is the strongest possible AES instance you can get
  • GCM is the mode which has seen the least amount of attacks, as predicable IVs are a non-issue and padding doesn't need to take place and authentication is built-in
  • GCM "only" provides 128-bit forgery security, but this is (a worthy / the) trade-off for a much better side-channel resistance
$\endgroup$
10
  • 1
    $\begingroup$ If you wonder where SHA-512 is: There's no standardized TLS cipher suite using SHA-512 as far as I am aware of $\endgroup$
    – SEJPM
    Jun 15 '16 at 21:50
  • $\begingroup$ So in theory it should be more secure, but ins't used because there is no support for it yet? $\endgroup$
    – blacklight
    Jun 15 '16 at 22:12
  • $\begingroup$ @blacklight I believe the argument for SHA-384 is that 128-bits of the state are missing. It gives an extra buffer of security against potential attacks which require the entire hash digest. $\endgroup$ Jun 16 '16 at 1:24
  • 2
    $\begingroup$ @SEJPM I don't agree with you AT ALL regarding choosing CBC-and-SHA over GCM. You are correct about IV reuse, but due to TLS's insistence on MAC-then-encrypt there are far more problems with CBC-and-SHA than with GCM. $\endgroup$ Jun 16 '16 at 6:00
  • $\begingroup$ @blacklight There likely will never be much support for this suite, because the combination is just stupid. After all it assumes you have SHA-2 but don't bother with GCM which is a very unlikely scenario and CBC is dangerous anyways (because of padding oracles and side-channels) $\endgroup$
    – SEJPM
    Jun 16 '16 at 6:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.