On Sun, 1 Oct 2000, Alexander S A Kjeldaas wrote: > On Fri, Sep 29, 2000 at 03:13:27PM +0000, Marc Mutz wrote: > > Hi out there! > > > > This little patch allows /proc/cipher/* to show a bitmask of allowed > > keysizes. Simple as it may ssem, it breaks the current jungle of > > #define's quite thoroughly. Ciphers that want to take advantage of this > > patch and actually _provide_ more than one keylength per cipher > > implementation (and most ciphers could), will not be able to use the > > DEFINE_CIPHER construct any more. > > > > 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. 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. IMO here should be possible to restrict some ciphers to predefined keylengths. -- Gisle Sælensminde ( gisle@xxxxxxxxx ) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (from RFC 1925) Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
