1

I know "SSL 3.0" and TLS 1.0 have weakness security, because using of "RC4" cipher. instead it, "TLS 1.2" have more security, now I want to use of a fast ciphersuite and a complicated handeshake method in "TLS" (for prevent of Man in the Middle Attacks).

It seems to me , key-exchange and ciphersuite methods should be as follows (priority respectively) :

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Now, which of Ciphersuites are fast and more secure in "TLS" handshaking?

BattleTested_закалённый в бою
  • 135
  • 8

1 Answers1

4
  • DHE key exchange is very slow compared to ECDHE, so you should prefer the ECDHE ciphers.
  • ECDSA is faster than RSA for the same level of security, but of course you need a ECDSA certificate and not a RSA certificate in this case.
  • AES-GCM is faster than ChaCha20-Poly1305 on systems with hardware support for AES but slower on systems without hardware support. You usually have hardware support on desktop system but it is missing on most mobile phones or tablets.
  • CAMELLIA seems to be in theory similar to AES regarding security and performance but usually lacks hardware support and is thus slower. See Why does nobody use (or break) the Camellia Cipher? for more information.
Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • "but it is missing on most mobile phones or tablets" - is this actually true on modern mobile platforms? I was under the impression that most mobile ARM cores had hardware AES acceleration support via the "Security System" instruction set. – Polynomial Jul 12 '16 at 12:01
  • @Polynomial: ARMv8 64bit got hardware support for AES but this is not yet the major architecture you will find in the mobile phones currently in use. See also https://calomel.org/aesni_ssl_performance.html, https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/ and https://bugs.chromium.org/p/chromium/issues/detail?id=585566 for some more information. – Steffen Ullrich Jul 12 '16 at 13:09
  • suppose i want to send data to a system in far way(consider long distance and tls latency and overhead, and trusted authentication), so, should i use of ECDSA or ECDHE? – BattleTested_закалённый в бою Jul 13 '16 at 04:16
  • @MohammadrezaPanahi: ECDSA (vs. RSA) addresses authentication while ECDHE (vs. DHE) addresses key exchange. Thus there is no "ECDSA or ECDHE" because these address different types of the handshake. You can use ECDSA+ECDHE but also RSA+ECDHE etc. Apart from that - if you care about latency on long distance connections all solutions perform about the same because the problem in this case is not the computational overhead but the speed and latency of packet transfer which depends on the line characteristics and not the crypto. – Steffen Ullrich Jul 13 '16 at 05:08
  • most importantly, is handshake security! i thing must choose a complicated method for this. what is your offer about it? – BattleTested_закалённый в бою Jul 13 '16 at 06:18
  • @MohammadrezaPanahi: these are all fine when used with the correct parameters. The security of the handshake depends on the key sizes used in the certificate, the ECC curve (ECDHE) and the DH key size (DHE). Thus means depending on these parameters the same cipher can be used in a more secure and less secure way. I really recommend you to learn more about [How SSL/TLS works](http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work). – Steffen Ullrich Jul 13 '16 at 06:52
  • @SteffenUllrich out of curiosity, how much is the difference between the handshake using the fastest cipher vs the second fastest cipher. Is it even noticeable if you have say 100 continuous new requests? – Limit Oct 24 '16 at 21:21
  • @Limit: I don't know about a difference about the ultimately fastest and the slowest one but a comparison of authentication performance with ciphers used in practice can be for example found at https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/ or http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html or https://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html. – Steffen Ullrich Oct 25 '16 at 04:37