5

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.)

Community
  • 1
D.W.
  • 36,982
  • 13
  • 107
  • 196

2 Answers2

2

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.

Community
  • 1
Henrick Hellström
  • 10,556
  • 1
  • 32
  • 59
2

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.

Richie Frame
  • 13,278
  • 1
  • 26
  • 42