5

I have been looking a bit at the various block ciphers for TLS. As everyone should (pipe dream) have migrated to TLS 1.2 by now it should be considered how to prepare for TLS 1.3, when it has been implemented.

In my daily work I have been looking into which block cipher algorithms to recommend for TLS 1.2 while keeping 1.3 in mind. On Wikipedia (the treasure trove of information) I found that AES-GCM could be a good candidate for the block cipher as it will be usable for TLS 1.3 and is one of the better ciphers considering performance (see Stanford presentation on AES GCM).

This question is in part "should I use GCM or CCM", however that is - somewhat - answered here. The important part - for me - is that the cipher to be used must be possible to compute and process using a small amount of transmission data. In my context I am limited by both processing power and amount of data to be sent, so could anyone suggest or give proof of which of the block ciphers supported by TLS 1.2 and future 1.3 are best in this regard?

EDIT: To answer the comment. The clients will not be browsers as such, they will use a channel secured by TLS. The engine... I am actually not sure that is fully decided. It is going to be on machines that are set up to connect to a centralized server. I realise this sounds a lot C&C-ish, but it is more IoT-ish. I hope that answers the question and helps in giving me a hint to what the answer to my question is.

Improve this question
3
  • 1
    What TLS engine are you using? And what clients must you service? I don't know a single regular browser that supports CCM. Not even Edge on Win10 or Chrome 48 on OS X.
    – StackzOfZtuff
    Commented May 10, 2016 at 10:12
  • No matter what, you need to consider tool support. Cipher choice is influenced by who's already implemented it. Don't pick an obscure cipher and then be limited forever in what tools you can use at some future date.
    – Steve Sether
    Commented May 10, 2016 at 19:09
  • I heartily agree on that. The clients are developed and controlled in the same organization as the "server", so all development considers both sides and is able to switch the tools in - most of - the stack at the same time.
    – RLFP
    Commented May 11, 2016 at 5:14

1 Answer 1

Reset to default
1

In my context I am limited by both processing power and amount of data to be sent, so could anyone suggest or give proof of which of the block ciphers supported by TLS 1.2 and future 1.3 are best in this regard?

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

Reasons:

  • CHACHA20-POLY1305 cipher suites are part of TLS1.2.
  • Is available on LibreSSL since 2.3.0 and will be added to OpenSSL 1.1 (to be released on 2016-08-25).
  • Is mobile device friendly and much more efficient (especially on devices that do not support hardware accelerated AES).
  • Offers 256bit of security by default (unlike 128bit for AES, in most cases).
  • Is compatible TLS1.3 as the new version will drop static RSA and DH key exchange mechanism (RFC). ECDHE will be preferred in most cases.
  • Is built using an Authenticated Encryption with Associated Data (AEAD) construction like CGM (weakened. Cause: nonce reusage initial paper, BHUSA2016 slides + original paper), CCM or EAX (broken).
Improve this answer
4
  • I like your answer, but the attack is only valid where a user is connecting to an attacker site. I my scenario the clients connect to a centralized server, the certificate of which is pinned, which eliminates the attack. However IF we are talking userland cases, I agree that the CHACHA20 cipher will probably be the way to go.
    – RLFP
    Commented Aug 17, 2016 at 7:50
  • 1
    What attack do you have in mind ? You asked for a cipher suite that would be supported by TLS1.2, compatible with TLS1.3 and suitable for devices with a limited computing power (i.e. mobile oriented). I need more details here.
    – ATo
    Commented Aug 17, 2016 at 21:24
  • My comment in the edit: "The clients will not be browsers as such, they will use a channel secured by TLS. The engine... I am actually not sure that is fully decided. It is going to be on machines that are set up to connect to a centralized server. I realise this sounds a lot C&C-ish, but it is more IoT-ish. I hope that answers the question and helps in giving me a hint to what the answer to my question is." The attack I refer to is the one in the slides you refer me to, where a user connects to an adversary, which should not happen in this case.
    – RLFP
    Commented Aug 18, 2016 at 5:16
  • 1
    Even if it's not supposed to happen thanks to your architecture choices, the server authentication (handled either through RSA || ECDSA) will solve the issue for you anyway. And again, considering that "The important part - for me - is that the cipher to be used must be possible to compute and process using a small amount of transmission data. In my context I am limited by both processing power and amount of data to be sent" I hope my post was useful in that regard (if so, feel free to mark it as answer).
    – ATo
    Commented Aug 18, 2016 at 6:35

You must log in to answer this question.

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