Followup to: <3989D185.65820D85@storm.ca>
By author: Sandy Harris <sandy@storm.ca>
In newsgroup: linux.dev.kernel
>
> Gerhard Mack wrote:
>
> The whole discussion of Canadian law is actually off-topic. The question
> is not whether we can distribute FreeS/WAN. We can, both from Canada and
> from the European countries with the web sites. If policies in one or
> more of those countries changes, we'll deal with that.
>
> The question here is whether crypto code can now be included in kernels
> distributed from the US, since US regulations have recently changed.
> It appears it can be, so it seems obvious it should be. Let's get
> back on topic and discuss what needs to be done to make that happen.
>
> Linus et al:
>
> What needs to be done to get the FreeS/WAB KLIPS (kernel IPSEC)
> patches into the standard kernel distribution? Or should the target
> be a KLIPS module that plugs cleanly into a standard kernel? What
> about the encrypting file system stuff?
>
> Anyone:
>
> Currently FreeS/WAN and the random driver each contain copies of MD5
> and SHA hash source code. There may be other duplications I'm not
> aware of. What needs to be done to get the various kernel crypto
> components to share code? How does this relate to similar work in
> user space?
>
Hi Sandy,
Thanks for bringing the discussion back on topic. You may want to
observe that the patch formerly known as the International Kernel
Patch (kerneli patch) is now archived on kernel.org as well as on
kerneli.org. This, we hope, is an early step toward integration into
the mainstream kernel. This will almost certainly *not* happen for
2.4.0, but may very well happen in 2.4.x for x > 0, and should
definitely happen in 2.5.
You probably want to get the kerneli patch and make your cryptographic
interfaces match as well as possible. Note that the kerneli patch is
of Norwegian origin -- the maintainer is Alexander Kjeldaas
<astor@fast.no> -- and so you can completely bypass the U.S. if you
want to make sure. Eliminating duplication probably centers around
creating a common in-kernel cryptographic API, and making everything
relevant (FreeS/WAN, kerneli, and random) use it.
Most likely, there will be no overlap between kernel and user space
cryptography, except perhaps in the support of hardware devices.
Software cryptography is almost certainly better done in user space
completely.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt- 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 Aug 07 2000 - 21:00:11 EST