Crypto and IPSec Merged into 2.5

Corbet writes "Linus has just merged the new crypto API and IPSec implementation into his 2.5 BitKeeper tree. This is the first time that serious cryptographic code has made an appearance in the mainline kernel, and it will hopefully lead to more secure communications for all Linux users in the future."

Comments

exportation issues?

[kochsr]

how does exportation work with this? i thought people weren't allowed to export code w/ serious type crypto in it.

Re:exportation issues?

[Angry White Guy]

I think that this would be the same as not letting Stephen Hawking leave the country because he knows too much

Re:exportation issues?

[JKR]

The requirements have been relaxed recently; see here for more details. In particular:

Also in 740.13, to, in part, take into account the "open source" approach to software development, unrestricted encryption source code not subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed using the source code can, without review, be released from "EI" controls and exported and reexported under License Exception TSU.

Jon.

Re:exportation issues?

[leto]

If you had followed the entire debate, you know
that these "relaxations" are declarations (yes,
those like a King makes), and can be withdrawn by Bush at any time, without any democratic process.
That's why Gilmore and Daniel are taking the stance they are taking.

Crypto is your fundamental right, not a fluffy
allowance from your Emperor.

Re:exportation issues?

[Skirwan]

exportation

Is anyone else subtly annoyed that 'exportation' is a word?

It sounds like something completifically inventorated, but sure enough the dictionary verificates its existification. I am extremifically annoyarated to be denyified this oppurtunitization to drop a Bush joke.

--
Damn the Emperor!

Re:Excellent - no more FreeSWAN patches

[LWolenczak]

somewhat, but from what I read bout a week and a half ago... the ipsec impmentation that they are putting in does not yet support ipv4 transport.... ie is useless unless you have hosts fully using ipv6 on both sides of the tunnel. Keep in mind, its not frees/wan, its from the linux ipv6 project.

With the atitude that the frees/wan project maintains, we will never see freeswan merged with mainstream kernel... hell... they still refuse to take patches from us citiziens and residents (that includes linus)

Too bad it's not Freeswan

[leto]

Too bad that full ipsec, such as provided by
Freeswan is still not in the kernel. I find it a
bit sad that Dave Miller and John Gilmore can't
figure out a proper way to resolve their problem

(John wants no US hands on the code, Dave wants
no code he can't touch in the kernel)

But at least the beginning is there, and if the
USAGI ipsec gets in, it should learn to talk to the userland tools, such as Freeswan, because Freeswan has extra features that "stock ipsec" doesn't have, such as Opportunistic Encryption.

Re:Too bad it's not Freeswan

[The Pim]

While I appreciate all the work that freeswan has done for us, I am much more confident for the long term in work done by the core Linux networking hackers. The freeswan guys seem much more concerned with making it work (in typical situations) than making it right, with the result that the implementation is horribly klugy.

Two examples are the need for a "nexthop" parameter, when the kernel already has this information in its routing tables; and the need to turn off route filtering. Both make it clear that freeswan is not properly integrated (and if you look at the freeswan docs, you'll see that this general problem been on the "to fix" list for a long time).

Kernel bloat ?

[MosesJones]

This is great that these things are comming as standard in the kernel, but so many things are "standard" now its getting pretty large for joe-schmo average user who will get a full kitchen sink kernel with their distro.

This is also great for creating products like VPN gateways et al, but is it time to consider a different structure for kernel builds, with modules being seperately managed with a smarter installation procedure.

Re:Kernel bloat ?

[Alioth]

With kernel modules you don't need to have the stuff loaded *in* the kernel all the time. All the distros I've used recently only have the stuff essential to run in the kernel image in /boot - the rest is all modules.

Re:Kernel bloat ?

[LordHunter317]

I can't believe everyone calles 32MB of source "bloat". 32 MB is small compared to soemthings on your system, like X, KDE, GNOME sources. And in a lot of way, the Kernel is a lot more featureful than any of those. X for example, has a lot of "bloat" due to its build system.

Joe-Schmo is goign to use the binary kernel supplied by his Distribution anyway, and probably never upgrade it, until he goes and downloads a whole new ISO image. The actual running kernel stays really small due to the use of such things as MODULES, allowing only what is needed to be running at any given moment to run.

Bitch Bitch Bitch. Stop bitchin' about stuff you really don't have any idea about. The kernel is for all intents and purposes, small, and is indcredibly featureful for its size. So deal.

Re:Kernel bloat ?

[GreyWolf3000]

This is great that these things are comming as standard in the kernel, but so many things are "standard" now its getting pretty large for joe-schmo average user who will get a full kitchen sink kernel with their distro.

This is also great for creating products like VPN gateways et al, but is it time to consider a different structure for kernel builds, with modules being seperately managed with a smarter installation procedure.

Due to kernel modules and the fact that you can "roll your own," the kernel can be as bloated as you want, the only downside is the size of the download. The current installation procedure works well enough for this, though the only feature it really lacks imho is querying dependencies satisfied by an entry.

Really though, kernels can and will always fit on teeny floppies, providing they're trimmed down enough. Regarding your comment about the end user getting the kitchen sink, have you ever looked at how distros handle this?

Most make a generic trimmed down kernel cross-compiled for the architecture and build all the modules. It may be the case that the distro copies hoards of modules, but that still isn't going to be as big a package as, say, glibc. If "joe-shmoe" doesn't have Bluetooth or scsi hardware, the corresponding modules won't get loaded, and as a result the bloatedness of the /lib/modules// directory won't bleed into the performance of the actual running kernel.

Re:Kernel bloat ?

[LordHunter317]

No, the whole kernel is about 32MB source. Binary is far smaller.

Don't compare a 43 MB binary download to a 32MB source download. That's apples to oranges.

Re:Kernel bloat ?

[GreyWolf3000]

If you roll your own, it is possible to get a working Linux system as small as you want, depending on the functionality. 5MB for a webserver--before compression!

Sources themselves are huge compared to the bins they create especially considering source trees for projects like the kernel and X, which have support for many architectures. Much of the source code doesn't even get into the binary in the end.

Re:Kernel bloat ?

[jim3e8]

If you want to see bloat, take a look at the commercial UNIXes.
For example, on a random HP 11.0 box here:

-rwxr-xr-x 1 root sys 18946872 May 9 08:43 /stand/vmunix

That is a 19 megabyte binary kernel. It would be interesting to see how big the source is...

Looking for FreeSWAN? Try freeswan.ca

[caluml]

I only found this out recently, but the freeswan.org site lags behind the actual development of freeswan quite a lot. A nice friendly guy runs freeswan.ca, and keeps it chockablock with all the latest patches and stuff.

I've mirrored the downloads as they're so useful.

Re:Looking for FreeSWAN? Try freeswan.ca

[velkro]

You bastard... you've /.'d my server! =)

Oh well, so much for hiding in anonymity.

ken@freeswan.ca

IPSec lets us get Win2k from the flank

[GreatDave]

In my experience, Windows 2000's support for IPSec is one reason why it has snared a foothold in many businesses. Having IPSec in mainstream Linux distributions would let us cut Bill off at the pass.

I hope we're not far from seeing adoption of Linux in places like the financial services industry. If the distributors can make IPSec painless to configure, Linux will make inroads in such industries very quickly.

Re:IPSec lets us get Win2k from the flank

[LWolenczak]

In all honesty, Win2k's IPSec impmentation sucks. It dosen't seem to be able to keep track of time... and it forgets esp tunnels like crazy. Linux is already being used quite a bit for the hidden thins in business. The firewalls.. The proxy servers, the VPN Routers. Linux makes a very good box to sit in the corner w/o a monitor, and run a few hundred ipsec tunnels with lets say OSPF on top of it all.

Many of the non-us distribuions ship with ipsec, but the big problem is creating some very easy way that can allow elmer fud to create a host to host or a subnet to host or a subnet to subnet ipsec tunnel in under 10 minutes. Preferably 2 minutes.

What is going to start shifting many businesses to linux is seeing applications such as AutoCAD run on linux. Seeing APIs for controling PLCs on factory floors. If we are able to woo the design and engineering firms to linux.... we will have a powerful foothold on the market.

Re:IPSec lets us get Win2k from the flank

[phorm]

Forget the "linux Vs windows" attitude for a moment, and lets just hope that the new linux kernel works nicely with the windows (bad or otherwise) implementation of IPSec for VPN, etc.

You'll probably snag a lot more users by showing cross-OS compatability as opposed to desktop replacement. As in most cases, it would likely be linux server, windows desktop, with VPN being a nice communication feature in both.I know that I would like my VPN's to work properly between OS's, without the half-baked configurations in FreeSwan.

Export Ramifications?

[nurb432]

Does this create any export ramifications since Linus ( and i assume the code he reviews/packages )is now located here in the states?

Just curious.. i know how hard of a time everyone else ( like BSD ) has with this garbage.

Information should never be restricted on the basis of governmental boundries. Phfft.

Re:Keeping stuff away from terrorists?

[DuBois]

No. Nobody can. Crypto can be used for good or ill, just like any self-defense tool. Keeping it out of the hands of "enemies" also keeps it out of the hands of people rebelling against our "enemies."

Freedom of speech also implies freedom of anonymous, or even encrypted speech, a concept that politicians have destroyed completely with "campaign reform."

Re:If I want IPSec stuff

[Teancom]

Well, seeing as this isn't FreeSWAN, maybe you want to restate your objections? I mean, complaining about FreeSWAN when talking about putting ipsec in the kernel, doesn't make much sense if it isn't FreeSWAN that they are using...

But on the other hand, who wants to read the article when you can, instead, spout off and look like an idiot?

Re:If I want IPSec stuff

[isa-kuruption]

I agree! The linux kernel is at least 2 years behind in any IPsec implementation compared to OpenBSD or even FreeBSD. What's going on here? Does that make sense? Usually it's the Linux folks that are ahead of the game, but not this time.

I guess the Linux folks wanted to make EXTRA SURE they didn't leave any BSD code in the kernel without a copyright before they added it to CVS.

Go ahead... troll me! I dare you!

Re:Mergint trends

[anshil]

KDE and GNOME merge, finally a common desktop for all.

Redhat and SuSE merge, and bring yast to redhat.

BSD and LINUX will merge.

The vim and emacs teams join together and will bring out a new editor together in teamwork.

Linus agrees on using CVS.

The english world will make a big grammar reform, enabling a polyphonic script again.

Star Wars will meet Star Treck.

America decides to officaly use the metric system.

The brits drive on the right side of the road. ...

Re:Excellent - no more FreeSWAN patches

[velkro]

Why no fork yet?

Because it's a large project, it's really complex, and it's a bitch to keep up with things.

I should know - I'm the author of Super FreeS/WAN, a pseudo fork with includes alot of patches (NAT-T, X.509 Certs, AES/Blowfish/etc... ) @ http://www.freeswan.ca/code/super-freeswan

It takes a few hours a day to stay on top of things. One the major ones is user support. IPSec is not easy to configure currently, especially once you introduce X.509 certs & MS Windows clients using any number of clients. So there's hundred of questions about configs, how tos, etc...

If you want to fork it, please, go ahead. Just remember that a fork isn't just the code - you take users with you.

Three kinds of bloat

[DickBreath]

One man's bloat is another man's features.

Hypothetical: I can't believe OpenOffice is so bloated compared to EDLIN from MS-DOS!

Maybe it's "feature loaded" instead of bloated? While it is true that you can use OpenOffice to duplicate tasks that you might have done in EDLIN, it is capable of so much more.

There is another kind of bloat which is not caused by features. This kind of bloat does not appear to be present in Linux. The kind of bloat I'm talking about is caused by "optimization". I don't mean optimizing for fast code or small code, but optimizing for "release date". Hey Mr. Customer, would take that new spreadsheet upgrade six months sooner if it required 25% more computing resources to run? All consumers I know would answer Yes. So this is a type of optimization. Optimizing for development time instead of optimizing for computer resources. Given the current low and decreasing cost of computer resources, there is some balance of this that makes sense. Just as once upon a time the "bloat" and value of high level programming languages was hugely debated. Now everyone uses high level languages to optimize for development time. The fact that I could spend six extra months doing it smaller and faster in assembler doesn't matter. Well, today it's the same thing. I don't mean that bad code is written on purpose, just that development time is valued above comptuer resources and machine optimizations, profiling, etc. Again, Linux does not appear to "suffer" from this type of "optimization".

Another type of bloat is just from plain bad programming. It was not a purposeful decision to optimize development time, it was just the the program is badly written. Linux does not appear to suffer from this kind of bloat either.

bloat

[budalite]

My un-favorite types of Bloat:
- In Apps, Games, whatever, it would be a lot nicer to be able to add features, rather than have the whole bloated thing copied/downloaded/installed onto your drive. (Cygwin has a nice setup.exe program that actually lets the user *pick* what he wants *before* the download. Very nice.)
- Programs that say "Standby while we figure out what system you are running" and then copy every bloated driver for every type system, and its various peripherals, that ever existed onto your hard drive, anyway. Maybe this is not a problem anymore with the huge disks that exists these days, but it does signify sloppy development work that is usually mirrored in the app. :{)||

More Pervasive Insecurities?

[brandido]

I am not very knowledgeable about security issues, but I am curious if the inclusion of security modules in the kernel will provide for a single point of failure. In other words, as more programs become dependent on the kernel module for security, if an exploit becomes available, will all these dependent programs become exploitable?

I ask this specifically because of the problem the IE ran into, where it depended on security APIs from Windows, the Windows API had an exploitable bug, and ta-da, IE had an exploitable bug.