Alexander S A Kjeldaas wrote: > <snip> > > 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? Hashing it or just using a cipher that can. > 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. > <snip> > > 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. > <snip> I'm sure there can be nasty consequences if you use a cipher that has a defined key length with another. It is true that most recently developed ciphers do in fact accept arbitrary length keys (up to a certain maximum), but they are _designed_ to do this. They have a matching key schedule algorithm that can cope with that. Blowfish accepts key lengths of up to 448 bits (being a _symmetric_ cipher) and Twofish up to 256. But doing some nasty things with the key bits before they are given to the key schedule will probably open the door for related-key attacks. It's the old tale: Use a cipher different than it was designed and you get into all sorts of troubles. Look at DES's S-Boxes. Change them in any way and you make DES weaker and sometimes trivial to break. Ciphers are fragile objects that should only be used "according to the book". Alex gave another reason: DES is a standard. You can't go and say. "Well, I have here these extra bits of entropy, lets throw them in somehow." How should this interoperate with other implementations. That's the way MS is using standards. Sorry. The main reason for the proposal of a keylength list in /proc/cipher/ was the need to have it in order for losetup to look it up. Currently there is no inexpensive way to gather allowed keysizes to present them in /proc/cipher/. losetup should be able to search that directoy and find the key length there. Marc -- Marc Mutz <Marc@xxxxxxxx> http://marc.mutz.com/Encryption-HOWTO/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
