I agree with Ian here; in fact, I've argued this before on this and other
lists. Why all these ciphers? It adds complexity to the protocol, makes
implementation a headache, and doesn't achieve the implied goal (providing
alternatives to fall back to if one of the ciphers is found to be broken.)
For the sake of argument, let's say there's a break in AES tomorrow that
makes it unsafe. Do we really expect users to jump through the necessary
hoops to update their key preferences, and then magically make all their
older copies of their keys go away? Or do we break backward compatibility
with the (now broken) previous implementations that used the (now broken)
cipher suites? New versions of the software that did this for the user
would be necessary.
In cases like this, you *want* to break backward compatibility, as it
makes it easier to clearly alert the user that the previous version is
insecure, and also helps force a swifter upgrade.
Note: there's no reason why there couldn't a smooth transition period.
Assume a second scenario, where, say, SHA-1 is found to be likely broken
within the next 5 years due to previously unknown weaknesses. (ahem [1].)
GnuPG or PGP or Mixmaster or Hushmail or the other implementations of
OpenPGP could put out a version that does both Suite 1 and Suite 2 for
some time.
Indeed, I think a lot of the cruft in OpenPGP that Hal was recently
talking about with regard to Simplified OpenPGP is due to the desire to be
backwards-compatible with the v3 keys; I don't believe that there *should*
be protocol-level compatibility between versions. Let the application
implement multiple versions, but don't pollute the next version of the
protocol with legacy considerations for the older one.[2])
(That said, I am not arguing for this change in view to take place in v4.
v4 is already a toybox for crypto-implementation geeks; let's continue to
use it as such, and have it out over what the One True Cipher Suite should
be later [3], clean things up in v5, and keep a clear wall between the two
versions, though they may be simultaneously implemented in the same
software application.)
[1] Given this rant, I assume now's a bad time to argue that we adopt
Whirlpool as our hash. I am becoming increasingly convinced, however, that
cipher suites that use AES should use Whirlpool.
[2] Upgrading user keys from one version to the next in a way that retains
certification signatures might be desirable, but doesn't contradict what
I am saying here unless those signatures are suspected of being insecure.
Unfortunately, given the current hash function situation, they are likely
to be, but either it's safe to migrate old signatures, or it's not,
depending on the circumstances. Trying to anticipate this ahead of time is
pointless.
[3] Therefore, I see no problem with assigning Camellia a number for v4
implementations -- we've already got an unmanageable number of
cipher-suite combinations, so what's one more block cipher?
--Len.
On Wed, 28 Nov 2007, Ian G wrote:
Werner Koch wrote:
On Tue, 27 Nov 2007 17:33, iang(_at_)systemics(_dot_)com said:
To me, this doesn't argue for 128 bit keys. You can achieve the same
effect by taking 128 bits of randomness and adding 128 0's on the end.
I just wonder whether Camellia been analyzed for such an "abuse" of the
key length. It is common practise to use random session key or use a
KDF to have a uniform distribution of the key bits.
Yes, use a key expansion function. I didn't mean to
literally tempt the gods.
What I am trying to do here is suggest ways to reduce the
work for implementors and maintainers, and also reduce
possibilities for confusion by users.
There is a view that OpenPGP is a fine way to experiment
with lots of different algorithms and lengths and modes and
colours. I once had that view as a developer, and once even
published a Java kit with lots of algorithms in it...
because it was so much fun to do all these algorithms!
But it is a conceit. The maintainer in me rejected that
approach within a month, and the architect in me now says
that there is only one true cipher suite:
http://iang.org/ssl/h1_the_one_true_cipher_suite.html
iang
--Len.