On Sun, Oct 01, 2000 at 02:56:24PM +0200, Gisle S{lensminde wrote:
> On Sun, 1 Oct 2000, Alexander S A Kjeldaas wrote:
> >
> > Why not just let all ciphers accept any key-length up to a maximum key
> > length, and have the cipher internally treat shorter keys as a
> > possible optimization opportunities. For example, the rijndael cipher
> > could exploit that kind of stuff to select the correct number of
> > rounds. So the user wouldn't really care about which intermediate
> > keylengths a cipher was designed for, just the maximum keylength it
> > was designed for.
>
> For some ciphers this may introduce security traps. The best example
> is 3DES. Now we accept 8, 16 or 24 bit keys and reject all other
> key lengths. This corresponds to DES compatibility, 2 key 3DES and
> 3 key 3DES respectivly. The parity bits are ignored. The problem
> is what we are going to do in the case where we have keylengths that
> don't fit into this. If we pad the key up to the nearest defined
> keylength we will get the possibility for meet-in-the-middle attacks
> against the cipher, which will reduce the complexity of an attack
> to around 2^56 work.
>
> If we on the other hand throw away bits to fit into a smaller key,
> we can also get in touble. The best example is when someone tries
> to use a keylength 14 or 15 bytes. then the security will be 2^56,
> since the lower key length is 56 bits. This will give the users a
> false imression of security. The worst case is maybe 14 bytes, since
> many people thinks that 14 bytes = 112 bits keylength, but miss
> the parity bits. They will belive they use a 112 bits key, while
> they only use a 56 bit key.
>
Third strategy. You don't need a "global" strategy for how you deal
with keys. For 3DES you could remove bits from the three keys in a
round-robin fashion so that none of the three keys are weaker than the
others by more than 1 bit.
I buy your argument that the very act of accepting a 112 bit key is a
potential trap, since you might very well be looking at a software
bug, and that returning an error would be a lot better.
But what if the user of the library actually _has_ 80 random bits that
he wants to use as a key. How should he be able to use 3DES? He
queries the interface and finds out that he can give 3DES a key with
56, 112, or 168 random bits (if we ignore parity bits). What should
the user do? The "obvious" tricks are dangerous to use for 3DES, as
you demonstrate above, while a 3DES-specific function could help him
get a key with as high security as possible from his 80 random bits.
> Both of the strategies will introduce potential traps, and a more
> advanced scheme will give surprises to the users, since we must
> introduce such modes. This will not be compatible with anything
> else either.
If we construct a 3DES-specific key-munging algorithm, it will be
"incompatible" with other software to a certain extent, and that's a
bad thing. I'm just trying to show/make sure that all ciphers _can_
handle a keys of variable length, so that the user of a crypto library
doesn't need to care about these issues. If the user doesn't need to
care about these issues, the interface doesn't have to be more
complex. I am no cryptographer so there might well be more traps with
such an approach though, so do not expect something like this to
appear right away.
> IMO here should be possible to restrict some ciphers to
> predefined keylengths.
astor
--
Alexander Kjeldaas Mail: astor@xxxxxxx
finger astor@xxxxxxxxxxxxxxxxx for OpenPGP key.
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
