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."
I really like the way the 2.5 kernel is progressing, a lot of the patches that I've been applying manually to the 2.4 tree have already been merged into the main tree of the 2.5 kernel.
:)
Can't wait until release, this thing is going to rock.
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.
countries with harsh import/export restrictions on crypto code? What will the impacts on
developers and users in those places be?
If not, can our government do something about it? I remember that during the cold war we successfully prevented our high grade crypto getting into the hands of the warsaw pact. Could we do the same thing now?
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.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Just for clarification.. thats 36~ meg compressed!
[KungFu] rmadmin:~$ ls -sh linux-2.5.44.tar.gz
36M linux-2.5.44.tar.gz
[KungFu] rmadmin:~$ gunzip linux-2.5.44.tar.gz
[KungFu] rmadmin:~$ ls -sh linux-2.5.44.tar
160M linux-2.5.44.tar
[KungFu] rmadmin:~$
Wanna rephrase your statement?
Can all fish swim?
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.
If frees/wan won't take contributions from the US why doesn't someone in the US fork it? Isn't this the way OSS is supposed to deal with stubborn maintainers that have different ideals than a large number of developers?
I expect the code is ipsec_tunnel by Tobias
:-) Something
Ringstrom... but I've not read the patch yet.
ipsec_tunnel is good code, after looking at FreeSwan and
deciding it was really poorly done, we looked at
this and even though (at the time) it was not yet
useable, we felt it better to contribute to it
to make a so then to go with the lesser
alternative.
Very clean, it's a fine design
worthy of inclusion in the kernel and a real
credit to Tobias.
D. Jeff Dionne
Arcturus Networks.
Anyone know if this will support VPN's using IPSEC wjhere either peer may be behind 1 or more firewalls? Right now, this has become an issue for a project I'm working on, and we're havin all sorts of issues. Thanks
2.00 + snapshots, and forthcoming 1.99 have vastly improved docs, and a way better inter-op doc.
I run OSPF + BGP over FreeS/WAN using GRE, which seems to be the simplest way to do it - there's been alot of dicussion lately on the lists about doing this.
Sorry to hear about the job loss, but when you get back on your feet and want to continue, just flip me a note and I'll give you a CVS repository if you want to start with.
ken@freeswan.ca
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
>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
Not 100% due to the attitude more than anything else. They by default choose not to allow single DES to protect users/organizations from themselves. Tell me a legitimate reason why, with today's hardware, you need only single DES? It is really not that secure in this day and age? In any case, when I set up FreeS/WAN on a system, two sets of patches immediately go on, x509 cetificataes (ala http://www.strongsec.com), and cipher plugins (http://www.irrigacion.gov.ar/juanjo/ipsec/). I usually do AES when going to other patched FreeS/WAN, and use the enhanced 3DES from that suite when dealing with implementation lacking AES...
AES is truly the way to go. There are a number of aspects of FreeS/WAN where they felt things the standards required to be available were too weak to be secure. They are mostly compliant with the specs, but I agree with them that certain things really have no use in security except to make things easier on organizations like the NSA...
XML is like violence. If it doesn't solve the problem, use more.