Re: Linux crypto?

From: James Yonan (jim@ntlp.com)
Date: Tue May 28 2002 - 13:28:58 EST


> On Fri, 24 May 2002, Alan Cox wrote:

> > > On Wed, 22 May 2002, Alan Cox wrote:
> > >
> > > > What of it do you actually need in kernel space - encrypted file
systems
> > > > certainly ought to be there but are not very well handled in Linux
proper
> > > > right now - but anything else ?
> > >
> > > IPsec.
> >
> > At the moment there doesn't appear to be an IPsec stack we can merge
however

> what about freeswan - with some cleanups?

I'd like to propose that network crypto can be handled well in user-space.

There are quite a few user-space options now for secure tunneling of IP or
ethernet. I am personally a developer on the OpenVPN project, but there
are quite a few others including VTun, cipe, and tinc. I know that
OpenVPN and VTun take advantage of the Universal TUN/TAP driver which has
been in the official kernel since 2.4.6 or so, which lets user-space
programs control a virtual point-to-point IP link or virtual ethernet
adapter. While not explicitly a crypto-enabler, the TUN/TAP driver nicely
imposes a modularization on secure tunneling daemons -- the bulk of the
code including crypto lives in user-space and the kernel component is
reduced to a small virtual network driver that talks to user-space rather
than hardware -- and which hopefully is sufficiently generic that it
doesn't fall into the class of crypto-enabling infrastructure with respect
to export-control regulations. Running in userspace confers a number of
other benefits such as:

1. the daemon is easily portable beyond Linux to any platform that
supports a tun driver (such as OpenBSD, FreeBSD, Mac OS X, and Solaris).
IPSec implementations tend to be OS-specific,

2. the daemon can use portable user-space libraries such as OpenSSL to
handle the crypto, taking advantage of the SSL/TLS protocol and the X509
PKI,

3. the daemon can tunnel over UDP (IPSec uses IP protocols 50 and 51 which
are often blocked by broadband ISPs),

4. the daemon can tunnel through NAT gateways (IPSec doesn't like NAT),
and

5. the daemon can transparently tunnel or bridge non-IP protocols or any
protocol which can be represented as an ethernet frame.

The downside of course is that a user-space implementation will be slower.
It's also difficult to achieve IPSec compliance, because user-space
tunneling daemons want to use an application-level protocol over UDP --
user-space is not the right place to implement a protocol stack.

But the upside is that the secure tunneling daemons are available now,
the better ones are robust, secure, and portable, they don't require
embedding any crypto or crypto hooks in the kernel, and they work
with most out-of-the-box 2.4 distributions without needing any external
kernel modules.

James Yonan
OpenVPN Developer
http://openvpn.sourceforge.net/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri May 31 2002 - 22:00:22 EST