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 PhysicsPGP-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/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:15 EST