Messages in this thread | | | Date | Mon, 07 Feb 2000 18:48:53 +0100 | From | Marc Mutz <> | Subject | Re: Encrypted File systems implementation into the kernel? |
| |
Sandy Harris wrote: > <snip> > > Not IDEA, since it has patent and licensing restrictions. > Well, AFAIK, IDEA is free for non-commercial use. I don't see a big problem there.
> If we are going to use any cipher from the IDEA and Blowfish > generation (designed after DES, resisting theoretical attacks > that work on DES (differential & linear), efficient in software > and using >= 128-bit key), then I'd say CAST-128 is the best > of those. See long complex argumanets on the IPSEC working > group list last year. > > I don't think this matters. We really only need one cipher in > the kernel. At this point, we should aim at AES. >
There are implementations for Blowfish, Serpent, etc. in the international kernel, properly made available for the CryptoAPI. Why waste these effords? Also, if you provide only AES you can be sure the developers that we want to use this API will implement their algorithms themselves again, be it only because of personal preferences. It is also always a good idea to have one fairly old cipher available that has gotten massive peer-review instead of blindly using the newest cipher.
<snip> > > 3DES is clearly a kluge; roughly 10 times slower than the Blowfish > and CAST generation in software. I see no reason to imagine it is > more secure. Others do, since it uses the heavily-anylsed DES as > its core; I'd rather have newer cipher that take account of that > analysis in their design. > > This is largely irrelevant, since 3DES is widely used and included > in standards such as IPSEC. Methinks we have to support it until > AES becomes so well established we can switch to using it only. > Several years, though we should do everything we can to hasten it. >
nod. The same arguments apply for Blowfish and so on. I really don't want to be limited to just one or two ciphers in the kernel. AFAIU the IPSec standard is open for various ciphers that are negotiated between hosts. Building a conformant implementation therefore requires to support most of them. Making an interface to implement new ciphers easily would also motivate people to write assembler versions for different archs and that would be very welcome because of speed considerations. Crypto is still something that cannot be fast enough.
<snip>
-- Marc Mutz <Marc@Mutz.com> http://marc.mutz.com/Encryption-HOWTO/ University of Bielefeld, Dep. of Mathematics / Dep. of Physics
PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |