Well, this is certainly true. The reason the United States would be conserned about the export of these machines is mainly because of their ability to crack encryption. First off, I think that controling the export of strong encryption is silly since all it means is that the other countries will have to develop their own algorythms or use stuff like blowfish that has been created outside of the states. The same goes with supercomputers or clusters. If someone wants it badly enough they will make one themselves. Now back to the topic. The reason that the supercomputer != beowulf argument is invalid in terms of code cracking is because you don't need fast io bandwith to crack encryption. This was successfully demonstrated by distributed.net and if you cluster machines, you have fast stable links for distributing key blocks/algorythm blocks to try and all of the machines are (hopefully) of the same design which simplifies the development of a cracking tool so that it can be excessivly (heh) optimized for one processor type. This idea applies to most incremental (versus realtime) tasks where supercomputers would win easily at realtime tasks while clusters would do fine with incremental tasks. This shows how trivial beowulf export control is, people with access to a number of workstations and a network could construct a beowulf cluster and use it for the same purposes as they would a imported complete beowulf cluster. I think that the government should be more conserned with securing their machines and developing better cryptography rather than trying to contain existing cryptography tools and hindering the intelectual development/security of other countries that are deemed unamerican.
I'd guess that this is the work stream.c, a ip stack bug which panics/freezes(resource wise) and is not FreeBSD specific. One of the original bugtraq post actually included a Linux kernel panic line from dmesg. Reports were also sent in that NT servers were down aswell. Stream works by creating as many open files/sockets as the system will allow thereby rendering it useless and from what I've read that its effectivness is proportional to the volume of packets sent so modifying the standard distributed dos tool to send stream packets and therefore downed yahoo. Chances are the only reason yahoo got attacked was because it was there not because it was the only large network that had that hole in it network stack. -Nick Chernyy P.S. for all of you paranoid FreeBSD users, there is a patch available and has been merged into the sources long ago.
Slashdot Mirror
Well, this is certainly true. The reason the United States would be conserned about the export of these machines is mainly because of their ability to crack encryption. First off, I think that controling the export of strong encryption is silly since all it means is that the other countries will have to develop their own algorythms or use stuff like blowfish that has been created outside of the states. The same goes with supercomputers or clusters. If someone wants it badly enough they will make one themselves. Now back to the topic. The reason that the supercomputer != beowulf argument is invalid in terms of code cracking is because you don't need fast io bandwith to crack encryption. This was successfully demonstrated by distributed.net and if you cluster machines, you have fast stable links for distributing key blocks/algorythm blocks to try and all of the machines are (hopefully) of the same design which simplifies the development of a cracking tool so that it can be excessivly (heh) optimized for one processor type. This idea applies to most incremental (versus realtime) tasks where supercomputers would win easily at realtime tasks while clusters would do fine with incremental tasks. This shows how trivial beowulf export control is, people with access to a number of workstations and a network could construct a beowulf cluster and use it for the same purposes as they would a imported complete beowulf cluster. I think that the government should be more conserned with securing their machines and developing better cryptography rather than trying to contain existing cryptography tools and hindering the intelectual development/security of other countries that are deemed unamerican.
I'd guess that this is the work stream.c, a ip stack bug which panics/freezes(resource wise) and is not FreeBSD specific. One of the original bugtraq post actually included a Linux kernel panic line from dmesg. Reports were also sent in that NT servers were down aswell. Stream works by creating as many open files/sockets as the system will allow thereby rendering it useless and from what I've read that its effectivness is proportional to the volume of packets sent so modifying the standard distributed dos tool to send stream packets and therefore downed yahoo. Chances are the only reason yahoo got attacked was because it was there not because it was the only large network that had that hole in it network stack.
-Nick Chernyy
P.S. for all of you paranoid FreeBSD users, there is a patch available and has been merged into the sources long ago.