5
$\begingroup$

Imagine I am a software developer. I want a block cipher, and I have the choice of using AES or Camellia. Which should I use? Which makes more sense from a technical perspective, and why? I need to select the preference order for TLS ciphersuites: should I put the AES ciphersuites above or below the ciphersuites?

For example, Firefox's SSL/TLS libraries currently list Camellia ciphersuites as preferred over AES ciphersuites. Is that the right choice? Should others follow Firefox's lead, or should they list AES ciphersuites as preferred over Camellia?

(See also Why does nobody use (or break) the Camellia Cipher? and Why is CAMELLIA suddenly so widely used?, which are related but not identical.)

Improve this question
$\endgroup$
6
  • 1
    $\begingroup$ ... And yes, I know how I would answer, and I know the answer (on a technical level) is likely to be painfully obvious to anyone on this site... but I'm hoping someone will write an answer that serves as a general reference that I can point others to. $\endgroup$
    – D.W.
    Sep 6, 2013 at 22:43
  • 1
    $\begingroup$ Technically, TLS only specifies that the server selects a cipher suite, and not how the order of the client cipher suites should influence this choice. If it does, it is an implementation detail. Hence, the only possible correct answer (that would have the same implications for any theoretically possible standard compliant server), is that you should only enable a cipher suite if you would find it acceptable that the server actually selects it. It is not really a question of which one is the best choice if you only get to pick one. If it was, simply disable the other. $\endgroup$
    – Henrick Hellström
    Sep 7, 2013 at 1:19
  • $\begingroup$ To be honest, the answer right now is AES128/256, even if just for the fact that no one can blame you for your choice in case a break does get found. I can't wait however until the new generation of tweakable 256 bit block ciphers have seen more scrutiny (threefish, BLAKE2's blockcipher and shameless self-promotion Orlein (paper quality not guaranteed)). A tweakable block cipher is so infinitely more useful. $\endgroup$
    – orlp
    Sep 7, 2013 at 3:35
  • 1
    $\begingroup$ The accepted answer in your first link -- written by... um... you -- looks very good to me. I am not sure what more you are looking for here. $\endgroup$
    – Nemo
    Sep 7, 2013 at 6:26
  • $\begingroup$ @nightcracker Totally off-topic to this question, but why is it common praxis not to include a date in a paper's PDF? I often read crypto papers wondering when they were written or first published, and then have to figure this out approximately from the references. $\endgroup$
    – Paŭlo Ebermann
    Sep 7, 2013 at 14:16

2 Answers 2

Reset to default
2
$\begingroup$

From a technical side, there are three general scenarios that should be handled differently:

Scenario 1: You control the configuration of the server your client software will connect to, and expect to retain that control for the life time of your client software. In such case, you only have to (and probably should) enable a single cipher suite, both client side and server side. Given a choice between several cipher suites that all meet your minimum requirements, and presuming there is at least one AES cipher suite in this list, choose that one (for the reasons stated here).

That said, you obviously would have to enable more than one cipher suite if you are bound by a security requirement to have a fall back option, e.g. in case the cipher suite gets broken and your software upgrade mechanism is more likely to fail, than your ability to reconfigure the server. This is however the only technical reason to enable more than one cipher suite in this scenario.

If you know that the server implementation respects the cipher suite preference of the client, it might matter how the client orders the cipher suites. Generally, though, the TLS standard does not specify how the server should pick the cipher suite, so this would be implementation specific and a better question for stackoverflow.

Scenario 2: You do not control the configuration of the server, e.g. because your client software might connect to multiple servers, but you do know the configuration of a required minimum of the servers. If there is more than one cipher suite in the intersection of the cipher suites supported by these servers, and that set contains at least one AES cipher suite, the situation is not much different from scenario 1, except possibly that you might be more likely to be required to include a fall back option in this scenario.

Scenario 3: You do not control the configuration of the server, and your security requirements are different for different servers and different users. The intersection of these requirements is the empty set. In this scenario you are basically out of luck. Your best option might be to make the client cipher suites user configurable for someone with administrator privileges, but that would fall outside of the scope of cryptography and be a better question for IT security.

Improve this answer
$\endgroup$
2
$\begingroup$

This depends on your intended use. If the hardware environment supports processor instructions for AES, that would be the preferred choice, as it will have higher performance and less side channel leakage. If you do not have these instructions, then from a technical standpoint each should have equivalent levels of security with a given bit size.

Ciphersuite choice is more of an interoperability issue, if you are working on a browser, I would follow Mozilla'ss lead, if you are working on server software, there are better ways of controlling the actual cipher used, although all modern browsers should support both ciphers. Either way, both ciphers should be implemented, with priority given to AES.

If you are working on a browser or server software, you should make TLS 1.1 and 1.2 the only allowable protocols, even if it breaks some compatibility.

Improve this answer
$\endgroup$

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