> "Michael H. Warfield" wrote:
> >
> <snip>
> > If these regs get finalized and are in the form we now expect them
> > to be in, can we get the paperwork filled and get IPSEC (and other crypto
> > goodies like ppdd) into the 2.4 kernel? KLIPS (from IPSEC) would be a
> > wonderful win! That would put us up with OpenBSD with integrated IPSEC
> > (OK, IKE, aka pluto, still needs improvement - but that's not a kernel issue).
> All those "crypto goodies" like CIPE, ppdd and IPSec (FreeS/WAN) are a
> mixture of a (usually small) kernel module and a userspace daemon (or
> setup tools). So you need to download the package anyway, because
> userspace and kernel are so closely coupled.
Your average user is not going to be downloading kernel patches and
rebuilding his system.
I think there's actually three issues here:
1) the US is not the only country with crypto laws. The question is
not whether the kernel will contain crypto, it's whether the
crypto patches will shipped with the kernel tarball or downloaded
from an external site (e.g., kerneli).
2) One thing that probably *has* changed is that it should be reasonable
to add a formal crypto API into the standard kernel. The kerneli
loopback API is a good model for this, and an API should be available
to both kernel and userspace callers. The standard package would
include a "null" module which immediately returns, so there would be
minimal additional overhead for the non-crypto user.
Crypto developers would write against the API. This should make
it easy for users to add stronger (or weaker!) keys as local
laws permit or require.
Non-crypto developers would be encouraged to add calls to the
crypto API, but it wouldn't be required.
3) Since the kernel will now contain a crypto API, the end user
who wants to add the userspace daemon now only has to ask two
questions:
- do I have the programs? This is no different than installing
ftpd from a CD-ROM.
- do I have the necessary cipher module? Again, the vast
majority of users will simply run their distro's kernel
module configuration file and select the appropriate ciphers
from a list.
This is no different than what's already routinely done.
I would not rush into adding crypto support just because it can be
done, but I think it's reasonable for 2.4 to have a basic crypto
API and null module. This lays the groundwork for the 2.4 distros
to add support crypto support as it becomes available. The
alternative is waiting until 2.6, or having the each of the
crypto modules reinvent the wheel. (Just how many DES implementations
does one OS need - and how would someone exploit a hardware driver
that interfaces to a hardware encryption chip?)
Bear Giles
bgiles@coyotesong.com
-
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 : Sat Jan 15 2000 - 21:00:26 EST