Linux-kernel mailing list archive 2000-06,: Re: Encrypted File systems implementation into the kernel?

# Re: Encrypted File systems implementation into the kernel?

Sandy Harris (sandy@storm.ca)
Sun, 06 Feb 2000 16:18:42 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Hans Reiser: "[Fwd: stuck on TLB IPI wiat]"
- Previous message: Ralf Wierzbicki: "Ami MegaRaid performance/2.2.14"

"Michael H. Warfield" wrote:

> > > What algorithms do we need?
> > > DES, 3DES, Idea, BlowFish...

Not IDEA, since it has patent and licensing restrictions.

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.
> > Renove DES! Add Serpent and the (five?) finalists of the AES
> > competition.

Serpent is one of the five.
Open soutrce code for all five is available from Brian Gladman's
page at:

http://www.btinternet.com/~brian.gladman/

but note that Brian says use is open "subject to any restrictions
the algorithm inventors may impose" or some such. A condition of
AES submission was that submitters agree to free access /if they win/,
but it is not entirely clear that this must be the case for losing
candidates.

We don't need five in the kernel. Put in any one of the three whose
submitters have already stated complete openness: Serpent, Twofish
or Rijndael. The other two are IBM's Mars and RSA's RC6; those folks
have not made a public commitment on openness (to my knowledge) if
they lose, so avoid those for now.

Whatever one we pick, do the interface so that substituting the
winner when they announce one this summer is trivial.
> Note for the unwashed... You technically can not remove DES without
> removing 3DES.

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.

> 3DES is three passes through the DES algorithm with either
> two keys (112 bit EDE mode) or three keys.

IPSEC requires the 3-key variant so that is what we shouls support.

-
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/

- Next message: Hans Reiser: "[Fwd: stuck on TLB IPI wiat]"
- Previous message: Ralf Wierzbicki: "Ami MegaRaid performance/2.2.14"