4

I have recently seen CAMELLIA, SEED and IDEA cipher suites in use for HTTPS on a web server and am unsure what to suggest to the owner. The keys in use are all over 128 bits in length and standard OpenSSL is in use.

IDEA was deprecated in rfc5469 due to it not seeing widespread use but may not actually be insecure.

Possible reasons to use the above cipher suites may involve being excessively paranoid about potential NSA interference and wanting to use Japanese / European / South Korean cipher suites instead. It is not affected by any local legal requirements to use these ciphers.

Possible reasons not to use these ciphers include they are not widely used across the industry so are likely to have been subject to less research by the security community compared to AES or other alternatives. It is possible someone may be able to develop side channel attacks by adapting those used against other ciphers but this is extremely unlikely for this server. Support from them has been removed from most modern browsers and I cant think of any situation where a client that could use these cipher suites would not support AES which was also available.

Beyond alerting the owner to the deprecation of IDEA and suggesting that it is generally a good idea to use the de-facto industry standard cipher suites, as these have had the most research performed against them, is there anything else I should be aware of?

2
  • 1
    If it's a South Korean site, might be down to legal issues, in which case, they're pretty much stuck with it...
    – Matthew
    Commented Mar 2, 2016 at 16:40
  • It is not a South Korean site so there is no legal need to use SEED
    – Stu W
    Commented Mar 2, 2016 at 16:55

3 Answers 3

6

In general, I would hope that all modern cipher suites supporting modern modes (at this time, generally GCM or CCM, with only GCM starting to become widely available so far).

This will allow mitigating future algorithmic weaknesses (such as RC4's progressive weakening) by disabling the known weak cipher while still having other, still strong ciphers already widely deployed. Having a variety of good, solid options is critical when flaws are found in one of them.

IDEA is ancient, 64-bit, and should be deprecated per RFC5469 as you noticed. I would recommend it never be used again.

CAMELLIA is a modern cipher accepted by the European NESSIE project in their final selection of algorithms alongside three other block ciphers (including AES).

CAMELLIA is also accepted by the Japanese CRYPTREC project in their Specifications of e-Government Recommended Ciphers.

I would recommend fully supporting CAMELLIA in GCM mode per RFC6367.

SEED is an older South Korean cipher; I would not recommend supporting it, especially as I am unaware of any GCM or other modern modes being available in TLS; only the old modes in RFC4162.

The more modern South Korean cipher is ARIA (RFC5469). ARIA has had several cipher suites added to TLS in RFC6209, including GCM mode suites which are worthy of strong consideration.

5

IDEA uses 64-bit blocks. This means that it begins to run into trouble, cryptographically speaking, if you encrypt more than 232 blocks worth of data with the same key (in CBC mode). That's 32 gigabytes, which is quite large, but not unattainable by today's standards. Thus, it should be avoided.

Camellia and SEED are block ciphers that exist mostly because the Japanese and Korean governments suffer from NIH syndrome. As far as we know, they are pretty decent algorithms -- just like the AES. There is no substantial reason to believe that they are stronger; if you are on the paranoid side, consider that if there is some unknown method by which the AES could be spiked, then there is no reason to believe that Camellia and SEED are not equally affected.

A practical reason to prefer AES is that there has been a lot more work on making constant-time implementations of AES. Also, some CPU offer some hardware support, which is even better for protection against side-channel attacks, and offers better performance. A typical Web server will not have any performance issue with any of these algorithms; whether side-channel attacks are applicable in practice or not is anyone's guess.

Still on the practical side of things, if clients don't support Camellia or SEED, then it is quite pointless to enable them on the server -- they won't be used anyway.

0

I don't see a reason to favor e.g. AES over other well tested ciphers. Even if IDEA and other ciphers may not have as much on going research about their security, they are not untested.

I think the bigger issue would be, that an older version of TLS (or even old SSL) is used. The attack surface created by this and additionally through bugs of older OpenSSL versions is much larger.

So in my opinion (I am not a cryptographer or security expert) the usage of well tested ciphers that are not very populare is not a problem. It does however not increase the security so there is no particular reason why you would want to use exotic ciphers.

You must log in to answer this question.

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