> > http://stackoverflow.com/questions/10378066/which-algorithm-is-stronger-for-tls-aes-256-or-camellia-256 > > which says: > > The reasoning is contained in the NSS library source code and is somewhat > convoluted, but it has nothing to do with security. It has to do with a > desire to support national vanity algorithms. >
If you wonder why NSS would prefer Camellia over AES (I sure did), here's the rationale. (Not a very good one, in my opinion -- if servers in certain countries are expected to have a strong preference for certain ciphersuites, those servers should override client preferences rather than hope that clients list them at higher priority than AES.) https://bugzilla.mozilla.org/show_bug.cgi?id=430769#c4 Nelson Bolyard (seldom reads bugmail) 2008-04-25 08:27:36 PDT [...] Putting Camellia ahead of AES and RC4 was intentional, but maybe we should rethink it. The rationale was as follows: - We presumed that Camellia would be implemented *and* enabled in few servers outside of Japan. Since it has not received anywhere near the amount of international scrutiny that DES and AES did, we thought that most server admins would not choose to enable it. We did not expect that it would be enabled by default in server products. (It is not enabled by default in NSS, as you know, but PSM enables it, apparently by default. Maybe the solution is to change PSM's default.) - Japanese server admins would prefer to use Camellia to AES or RC4 whenever it can be negotiated, however, most clients deployed do not yet implement it. Most clients deployed DO implement RC4 and/or AES. Therefore, it is not yet feasible for servers in Japan to disable RC4 and DES, because they want to communicate with a wide range of clients. It was reasoned that if Camellia was arranpreference than AES or RC4, it would only be chosen if and when either the client or the server or both had disabled both AES and RC4, which (as explained above) was thought to be unlikely to happen unless and until Camellia becomes more widespread. If you think we should consider an alternative prioritization of the ciphers in NSS, and/or consider having separate priority orders for the client and the server in NSS, please file a bug on that. I don't think it's a bug or a bad thing that clients are using Camellia in the wild. I just noted it to mark the historic occasion of the first sighting. :) https://bugzilla.mozilla.org/show_bug.cgi?id=430875#c2 Nelson Bolyard (seldom reads bugmail) 2008-04-25 17:39:08 PDT I think it is fair to say that, even before the addition of Camellia, there was an exception. RC4 was given priority over 128-bit ciphers, even though it is thought to be weaker than any other 128-bit ciphers. This was (and is) due to the fact that it was far more performance than any other 128-bit ciphers, and performance has always been very important to nearly all SSL users. We also rationalize that those who really want AES or DES could and would disable RC4, because implementation of AES and DES are so ubiquitous that disabling RC4 was not likely to prevent interoperability. Now, with Camellia, we a third motivation for prioritizing ciphers; one that is neither purely one of strength, not of performance, but of national pride. The situation with SEED, if it is ever introduced into NSS, will be the same. IMO, neither algorithm is likely to ever reach the level of ubiquity of the other ciphers we have now. The major, peeason to use any of them will be national pride, IMO. IMO, Ultimately, the best way to deal with this, the way that will make the largest number of people happy, is to have user-selectable priority ordering of cipher suites. The problem with that is that the API and GUI for presenting that prioritization problem to a user or administrator is large, and IMO, products will be loath to do it. Firefox has already removed the GUI for even simple enabling and disabling of cipher suites, so I think it is highly unlikely that they would ever implement a GUI for prioritization of cipher suites. So, until we have user-selectable priority ordering, I think the way to go forward is to take those cipher suites that will be used predominantly for national pride, and disable them by default. The Cammeria suites are already disabled by default in NSS, but are enabled by default in PSM. Perhaps it would be appropriate to enable them by default in localized Japanese builds, and not in others. Comments?
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
