Slashdot Mirror
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."
Jon.
how does exportation work with this? i thought people weren't allowed to export code w/ serious type crypto in it.
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.
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.
An Eye for an Eye will make the whole world blind - Gandhi
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.
Get your own free personal location tracker
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.
"I am root. Bow before me." To this I say, "You are root, and you bear the sins of the world upon your shoulders."
Oh man...
First ICQ and AIM merge.
Then Crypto and IPSec merge.
Next you're gonna tell me that cats and dogs have merged.
What's the world coming to?
"It's a tarp!" -- Dyslexic Admiral Ackbar
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.
---- Booth was a patriot ----
Freedom of speech also implies freedom of anonymous, or even encrypted speech, a concept that politicians have destroyed completely with "campaign reform."
The IPCC has purposely engineered a massive scientific fraud.
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?
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!
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.
I'll see your senator, and I'll raise you two judges.
Linus has yet to post a message to linux-kernel since his return, but he continues to merge patches at a high rate.
What's cool about this is that people are watching kernel development without having to read the lkml or being on irc or whatever. People can now just watch the patches flow into the bk system. I think that's kind of cool. It's like a Kernel News Network.
www.rdex.net
Wouldn't this run afoul of many of the U.S. Cryptography export regulations? U.S. DoD prohibits exporting of any product containing mathematically "strong" cryptography (usually, 128-bit) to a lot of places.
That, and the DMCA which prohibits reversing of any of the encryption that would be found in the new kernel, would create a risk for many of the users downloading the software if they were from anywhere outside the US (and, for US users downloading the software, because it couldn't be explained to them.)
I'm sure the U.S. government is going to have a lot of fun with this...
>The only reason I can think of why you want this, is when you have a dynamic IP address and you want to use a Preshared key.
So I see. Basically any home user using an ISP shouldn't expect to ever have any kind of crypto at all because it is slightly weak.
Next up: Master quits making front door locks. States that most homes have windows and therefore their locks are ineffective, so they will quit selling them altogether.
A lack of Agressive Mode (among other things) is the _only_ reason my previous ISP didn't support Linux. In fact, they wanted to support Linux, and eventually switched over to a non-encrypted system and released a Linux client for it.
So, who really wins in the end? Nobody. Ho hum.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
Or the banning of Linux in several countries. Whichever comes first, you know.
Maybe the state's highest function is to grind out insoluble problems. (Zelazny, Hall of Mirrors)
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.
Western crypto restrictions had nothing to do with breaching the Berlin Wall, for example.
The IPCC has purposely engineered a massive scientific fraud.
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.First Falcon-1 to orbit, then Falcon-9. Then I can die a happy man.