Slashdot Mirror

Because distributed.net is a purely volunteer project, many of its staff also have their paid day-time jobs working for United Devices (who are responsible for the THINK Cancer project). That includes myself, Nugget, Decibel, Moose, Moonwick

Because distributed.net is a purely volunteer project, many of its staff also have their paid day-time jobs working for United Devices (who are responsible for the THINK Cancer project). That includes myself, Nugget, Decibel, Moose, Moonwick

Because distributed.net is a purely volunteer project, many of its staff also have their paid day-time jobs working for United Devices (who are responsible for the THINK Cancer project). That includes myself, Nugget, Decibel, Moose, Moonwick

Because distributed.net is a purely volunteer project, many of its staff also have their paid day-time jobs working for United Devices (who are responsible for the THINK Cancer project). That includes myself, Nugget, Decibel, Moose, Moonwick

No, they can't shut down yet! I have to break 10,000 in the rankings!

Good Lord, what shall I do? :(

Straight off Distributed.net's main page:
"Unauthorized Worm: We have recently learned that an infectious worm has begun circulating around the Internet deploying copies of our dnetc client. If you are looking for information relating to this worm then visit our trojan page. "

As opposed to your "authorized" worms?!?

The RC5-64 challenge is currently at 73%, moving fast. Can you imagine the project shutting down just now?

How does it relate to the RC5-64 challenge? Hmmm. Millions of killowatt hours were donated to the RC5-64 cracking project. Now if that money were donated directly, a machine could have been built instead. RC5 is only 64 bits so it would be trivial to crack it with a dedicated machine.

Namely - aren't most modders and overclockers running the distributed.net client, or some similar background task, which keeps our CPU utilisation at 100% all the time?

I could draw a tachometer on the front of this PC, and it'd be 100% accurate :-).

As a matter of fact, given that amount of money the simplest way to force the system is an exaustive search on the 3des keyspace (yes, 3des is the algorithm)

This part makes me wonder if you're trolling. Well, if so, I bit. Searching the 3DES keyspace is not currently feasible, and won't be for quite some time. 3DES has an effective keyspace of ~111 bits (it's 112, but the complement property of DES keys, plus a number of weak keys reduce it by 1 bit and change). That's a keyspace that is 70,368,744,177,664 times larger than the 64-bit keyspace that distributed.net has been working on for over three years, and 18,014,398,509,481,984 times larger than the one Deep Crack can search in a week. Actually, Deep Crack isn't really set up to attack 3DES (because it's infeasible and the EFF guys that build Deep Crack aren't stupid), but if it could, this means that finding a 3DES key would take, on average, 346,430,740,566,961 years. Of course, Deep Crack only cost $250K, and that was a couple of years ago, so more money and newer technology might be able to reduce that by a factor of 100 or so. Hell, assume you can do 1000 times better, Then you'd only need 346 trillion years.

112-bit keys won't be safe forever, but they'll be safe for the next decade or two at the very least, barring the discovery of flaws in DES, which has successfully stood against all comers for nearly 30 years.

Regarding power analysis, see my other post on why power analysis is dead. Timing analysis is similarly infeasible.

Is switching to FreeBSD an option? The virtual memory management there is much better than in Linux under stress.

I'd have to agree. The author should look into using FreeBSD. A GIS project I'm currently working on allocates 3GB of RAM at startup. Until we get the rest of the funding for our SunFire solution, we're using what we have available, which is (was, actually: we've replaced the OS with FreeBSD) a P4 Linux box with 2GB of RAM, a 9GB SCSI drive for swap partition and a 36GB SCSI drive for everything else.

I'm not a Linux expert, but the techs in the department are. After a few weeks of their tinkering, it did pretty much the same thing as you're experiencing. I have a small development system at home (P3, 1GB RAM, 4GB SCSI swap, 40GB IDE for all else) running FreeBSD. Installed the software, and it runs like a charm. X works beautifully, Apache still serves up pages (of course, it doesn't get much traffic at home) and the program never chokes the system. Granted, with only a gig of real memory, it spends a fair amount of time accessing the disk (about 30 seconds every 2 minutes), and it steals almost all the cycles from dnetc!

From the CNN article: If the card is stolen, officials say the data on the chip can't be easily retrieved. This is probably not true. Check out:

Tamperproofing of Chip Card(s) - abstract: There are two ways of attacking smartcards - destructive reverse engineering of the silicon circuit (including the contents of ROM), and discovering the memory contents by other means; a well equipped laboratory can do both. Persistent amateurs have often managed the latter, and may shortly be able to do the former as well.

Tamper Resistance - a Cautionary Note - abstract: An increasing number of systems, from pay-TV to electronic purses, rely on the tamper resistance of smartcards and other security processors. We describe a number of attacks on such systems - some old, some new and some that are simply little known outside the chip testing community. We conclude that trusting tamper resistance is problematic; smartcards are broken routinely, and even a device that was described by a government signals agency as `the most secure processor generally available' turns out to be vulnerable. Designers of secure systems should consider the consequences with care.

With any cryptographic system, it all comes down to one concept: time. With enough time and resources, these cards CAN be broken, overwritten, you name it. We have seen ubiquitous evidence that even the strongest cryptography can be broken in time. HK is planning on using these SmartCards as digital passports. "Smart card holders will speed through Hong Kong immigration, using self-service kiosks that match digital biometric data on the card against the cardholder's fingerprint image read by a scanner."

The scariest part, for me, is that HK is setting a precedent. And it won't take long for other countries to jump on the bandwagon.

I wonder if it's still doing something... like distributed.net.

Or is it just flying through space, 100% idle? :-)

When Beowulf clusters came out (obligitory reference) lots of 'unbreakable' encryption was considered suspect (eg DES) Any encryption system is only secure for a limited amount of time. When new hardware/software comes out the limit is shortened.

Not so fast. Moore's law states that transistor density (and thus computer power per square foot) doubles every 18 years, and a doubling of computer power reduces effective key length by only one bit. Given that one of the world's largest clusters hasn't yet cracked a 64-bit key, barring some sort of quantum breakthrough, I see a 128-bit key as potentially running into the limits of the silicon that underlies our current classical computing architecture. Do you really believe that Moore's law will hold for the next century (i.e. time for 64 doublings)?

Eg don't put a $40,000 dollar lock on a $2 product.

More like a $2 million product if you sell one copy to a pirate who makes 2 million copies through a peer-to-peer file sharing network.

SETI sucks. distributed.net!!!!!!!!!!!! w00 yea.

You are pretty clueless, or can't read. Go to their site, and learn what the purpose is. Stoking egos is merely a by-product.

Why even bother their servers at all? SETI should wait until we have our own world's problems figured out. Please visit Folding@Home or Genome@Home for two ways you can help solve actual problems. If solving geeky problems is more your style, visit d.net.

I'm not sure whether or not this is a good thing or a bad thing. Lemme elaborate.

Disclamer: I have never been part of SETI@home; I feel that statistically it's a collossal waste of time. I've been part of both the GIMPS project and the distributed.net RC5-64 projects for about four years now. I've got the Kevlar body armor halfway on.

The good, I guess, is that there's such a collossal interest in this. I mean, hell, if KzAplOcQQ and boB are sharing the Encyclopaedia Galactica (or the Hitchikers' Guide, whatever) over radio waves, then we'll eventually find it hopefully in something that resembles paEr Unicode.

However, I see a great many downsides to this.

First off, if the aforementioned theoretical KzAplocQQ and boB of the paEr race have to use radio waves, then there's a pretty good chance they haven't been able to go superphotonic, in which case we're going to have a long wait before we can even think of going to their New York and flipping them the left tentacle.

Secondly, how will we be able to decode a xenic dataset, much less their language? I mean, what if they can transmit trits or quaytes while we're looking for bits or bytes? How do we know what a newline would appear? Hell, do we even know if it would even be necessary? And what about the characters? What if the Chinese language is easier to interpret than paEr?

Third, there are much better uses of free cycles, at least fiscally. GIMPS will provide a hundred kilobucks to the first person to successfully find a ten megadigit Mersenne prime. distributed.net provides a two kilobuck prize and a large donation to the FSF, EFF, or other worthy charities. Even the commercial distributed computing projects at least pay for the use of your rig.

(PS: paEr is a theoretical name for a xenic (alien) species, contrived from randomly entering characters on the number pad. KzAplocQQ is an unpronouncable name, unless you're lucky or high. boB just sounds funny.)

Distributed.net is also looking for new members!

willy

These chains of dependent instructions can also be parallelized with SIMD instructions. RC5 is not a measure of how good your processor is, it is a measure of how fast you can do ROTLs.

At the risk of sounding argumentative, how fast you can do ROTLs is a measure of how good your processor is, if doing ROTLs is what you need to do. Of course, Apple hypes this capability mercilessly, but they have some justification: SIMD (Single Instruction, Multiple Data) is, by definition, very good at situations when you want to do the same operation on a masses of data -- which is exactly the case when you're dealing with large graphics or audio, the Mac's traditional strong points.

I believe that altivec provides a SIMD version of ROTL which is why G4s do well.

Your belief is correct.

In contrast, [...]
The Pentium-4 takes 4 clocks to do a ROTL. Yikes.
Athlon takes a single cycle for the ROTL.

And the G4 takes a single cycle to do four ROTLs. It could do up to 16, but the RC5 code needs to rotate longs, not single bytes.

Anywho, it's bedtime, and I'm passed my daily linking allotment.

]:8)

Production systems are controlled environments - last thing you need is some unaudited, unexpected and unauthorised changes messing them up.

...or opening up a security hole.

Every piece of software installed present a potential threat. Did it come from a reliable source? Does it have security flaws? Obviously, there has a be a reasonable balance between maintaining security and giving users the flexibility they need to do their jobs. I get very irritated when a company won't let me install software I need -- or just want! -- on my desktop at work.

This balance tips increasingly in favor of security as if installation is (1) on a server, (2) on a production server, (3) on a lot of machines. Maintaining that balance is a sysadmin's job. And this guy was definitely not doing his job.

All that said, aren't criminal charges just a little out of line? He should just have been professionally reprimanded, or maybe fired. But a lawsuit?

I'm sorry but what the hell is dnet going to prove besides searching a given keyspace takes X amount of time? God I can't wait to start an account for RC5-1024 that my great great great 6 armed moon children will still not have broken. At least the golumb ruler stuff has a mathematical purpose,
OGR's have many applications including sensor placements for X-ray crystallography and radio astronomy.
Seti@home however flawed its methods maybe right now will through virtue of elimination allow even more thorough or refined searches in the future. What does cracking encryption ala brute force teach us, nothing.

I started to say "As I understand the distributed.net scheme", but then I realized I didn't, so here's the cut & pasted version:

RSA Labs is offering a US$10,000 prize to the group that wins this contest. The distribution of the cash will be as follows:

* $1000 to the winner
* $1000 to the winner's team - this would go to the winner if he wasn't affiliated with a team
* $6000 to a non-profit organization, decided by vote
* $2000 to distributed.net for building the network and supplying the code

(from http://www.distributed.net/rc5/

Distributed.net

He ran the dnetc.exe client on a ton of school PC's in Georgia.

The funny thing, is that it took several "security experts" a lot of work to figure out what dnetc.exe actually was :)

My question is, why did it take so long to break a 40bit key? After all, EFF's "Deep Crack" (now there's an unfortunate name!) broke 56bit DES in 56 hours, almost exactly 3 years ago!

And another thing, what on Earth is an al-Qa'ida terrorist doing with a laptop? I understood their position to be totally anti-technology - apart from guns and bombs of course...

The latest iteration of the Deep Blue computer is a 32-node IBM RS/6000 SP high-performance computer, which utilizes the new Power Two Super Chip processors (P2SC). Each node of the SP employs a single microchannel card containing 8 dedicated VLSI chess processors, for a total of 256 processors working in tandem.

Integral to the mathematics of the RC5 algorithm are 32-bit rotate operations. For whatever reason, the designers of the IA32 (32bit Intel x86) and the PowerPC architectures decided to implement the rotate function as a hardware instruction.

Many other CPUs do not have built-in hardware rotate instructions and must emulate the operation by (at the very least) two shifts and a logical OR. This handicap is why many non-32bit-Intel [1] and non-PowerPC computers run RC5 slower than one might expect based on real-world benchmarks. It is also the main reason why the RC5 client is a poor benchmark to use in determining the speed or performance of a particular CPU.

[1] The IA32 architecture is that used by the Intel 80386, 80486, Pentium, Pentium Pro, Pentium II, Pentium III and Pentium 4 processors. The Pentium 4 does not however have a hardware rotate instruction.

I wonder if they have been taking McOwen to court if has run something that could actually save lives on the department's spare time.
I think they just decided to use public opinion against "cracking" and made McOwen a criminal ("Look, he's trying to break codes on company time. He must be a criminal"). Sorry, not criminal, what's the buzzword again? Ah, terrorist...

Maybe this is a crazy idea, but could we have them compute a block for distributed.net or SETI@home? Two birds, one boulder..

this page lists a G4 at 1.6Ghz, but remember, this is user-entered data, there is no verification.

It has been done. I can't remember off the top of my head which one, but I cleaned up a virus infection about a year ago that installed the distributed.net client.

Its gotten bad enough that Symantec has posted a KB article on it, here.

Distributed.net also has a trojans page here.

---
www.symetrix.net

(1) Any government agent could crack your encryption...after all, a quantum computer could crack a fifteen thousand letter password in like two seconds. (of course, not for PGP, since it is based on unsolvable algaebraic formuli)

If we don't get a more secure encryption system out before the real quantum big guns come out, e-commerce etc is basically stuffed.

As a computer security professional, I am often reminded of that quote when I read about new networking technologies. And I stop to ask myself: is the added convenience of adopting this technology really worth the potential risk of allowing complete strangers who might not have our best interests in mind to access our networks and see our traffic?

The classic counterargument that I usually hear to my pessimitic remarks is something along the lines of "encryption is a panacea," in so many words. But is it really? Is the HomePlug(tm) product really designed well enough to keep intruders from peeking into my personal life? Well, let's think about a couple of points:

• Encryption schemes get weakened or broken. That makes a "useless" collection of your sniffed packets very useful for the snoop who hasn't erased his logs yet.
• 40 bit WEP didn't work. 128 bit WEP was broken soon after it was introduced. Apparently more bits doesn't help when there are easier ways to break these systems than with brute force.
• Traffic patterns can easily be deduced from encrypted communications. I'm not a big fan of Solar Designer, but I'll admit that the work he did in analyzing SSH and guessing passwords based on keystroke timing was brilliant. Who's to say that somebody won't find a way to do that for some sort of wireless transmissions?
• This does nothing to prevent DoS attacks. So if you anger your next-door neighbor, he will probably try to flood your network with crap. As a computer geek, I know this would make my life miserable.

df

Moores law says nothing about computer speed doubling. It refers to the transistor count doubling.

Distributed.net relies on the fact that all other factors being equal, brute-forcing a key (decrypting a message with all possible keys) scales linearly with the number of processors involved because of the inherent parallelism. If transistor density doubles, the number of crypto datapaths you can put on a given-sized die doubles. Therefore, Moore's law of gate density translates directly into speed increases.

The security of AES is currently being hailed as the fact it has a key field 10 to the 21 times larger than 56bit DES. Great. Only an idiot would try to brute force it though, so the number of keys is somewhat arbitrary.

Key length is, of course, vitally important. Understand the Rijndael spec. before you continue your speculation. Also, many "idiots" try to brute force it. Effort required to force a key is proportional to the cipher's weakness.

Less generally, by employing lack of symmetry and a non-linear layer in the cipher, AES pretty much gurantees that you'll simply be searching the key-space at random. If you can come up with a way to do better than a brute force, you should quit your current job.

The 2^255 Rijandel iterations required to force a 32 byte key is certainly sufficiently secure by todays standards, but historically consistent increases in computing power coupled with increased distributed processing ability due to networked computer proliferation means that keys will have to keep growing to stay resonably secure.

No way! Faster CPUs give you a higher BogoMIPS rating! And besides... the working set of some programs is small enough to fit in cache (both L1 and TLB), and gain a proportional performance advantage from increased CPU speed (after being optimized for the core.)

An inexpensive RC5 Crunching Cluster. That would be nice.

Cancer drug research
Gene research
Protein folding

All of these distributed projects reach into medical research and are as such a bit more useful than searching for ET or cracking RC-5.

The PIN is four decimal digits = 10,000 combinations ~= somewhere between 13 and 14 bits of security.

For those interested, you can find how many bits a key with x values is using logarithms:

bits = log(x) / log(2), or

bits = d / log(2)

Where d is the number of decimal digits the key is. Therefore, a 4-digit PIN has 4/log(2) or precisely 13.287712379549449391481277717958 bits of cryptographic strength. Not much compared even to weak encryption such as 64-bit DES, or the 56-bit des-ii cracked by d.net.

Your "average" user, in all likelihood, isn't running 100% processor intensive tasks.

Ummm... I guess dnetc.exe doesn't count, huh? :)

Wouldn't it be a better idea for today's PC game development shops to distribute their own customized OS' with their games

This has been tried before. Some of the really old games, like Wizardry < VI, ship on a floppy diskette. The system requirement says "100% IBM compatible computer", XXX kB RAM, etc. You boot from the floppy, and the game loads.

I've seen a few people talking about bootable Linux-based CD/games that would work the same way. The problem here is the astronomical complexity of the "PC" hardware platform, with thousands upon thousands of different cards for video, sound, networking; SCSI vs. IDE; ATAPI vs. proprietary CD-ROM interfaces; etc. Your game would have to support all of that.

Also, people do not like to reboot their systems to play a game. If playing Civ3 meant I had to give up the rest of my Linux desktop (including xmms playing music for me), my distributed.net client, etc., then the cost (hassle) of playing the game may be too high.

From what I've seen the machines are just too slow to run anything heavier than CDE. We have Ultra 5/10s here with decent amounts of RAM and even CDE seems slow to me compared with Windows/Linux machines (try turning on the "display window contents while dragging" option and watch them repaint the screen in real time!).

The 400mhz processors in the Ultra10s are no racehorses by any stretch of the imagination - I ran benchmarks with them (using the distributed.net client) and they turn in scores less than 1/5 of my Athlon 1.4. Coupled with this, the video is abysmal (do they have ANY graphics acceleration?) but then "vi" doesn't need that much CPU power :-)

Much as I like using Ximian/Gnome (without Nautilus) on my x86 linux boxen, I think it'd run like a dog on a typical Sun workstation...

my PC is never idle!

http://www.distributed.net

• 179769313486231590772930519078902473361797697894 23 06572734300811577326758055009631327084773224075360 21120113879871393357658789768814416622492847430639 47412437776789342486548527630221960124609411945308 29520850057688381506823424628814739131105408272371 63350510684586298239947245938479716304835356329624
• 
  224137216

It's 309 digits long! As you can see the numbers are big and get exponentially bigger as the key size increases. The idea with public key encryption is that, while it is quite quick to multiply two numbers this size together, it is very hard to factor the result into the two parts again. It is possible but, for keys > about 56-bit, it is beyond what modern computers are capable of.

Distributed.net is a SETI@home-like project to crack ever larger keys, among other things. Check them out.

I read that Tom's article and it got me thinking (I use a Athlon TBird 1Ghz). It's aloways been hot. When it's on for long periods of time, the office gets hot, when I run a spare-cycle slurper it stays REALLY hot. I've never actually had a problem I could trace back specifically to heat, but it's always been an issue with this CPU. I bought an really fast fan for it, and it was WAY too noisy. The generic one should be could enough. At the very least, I'd like to know that the CPU would protect itself (Intel's either shutdown or slowdown, see the recent Tom's Hardware article about overheating Intel vs. AMD). Could this be part of Gateway's decision? Are these chips just too hard to cool? When you really think about it, the TBirds have an enormous amount of heat disapating from a very small area. Seems like a broken design. At least from a longevity point of view.

Awe man your gonna make me open up a whole can of worms and links.

>>Terrorist = exacto knife
>>You = exacto knife
I'm talking about the armor wearing terrorist on the street, you don't think they exist?

>>How many terrorists carry AK-47s in this country?

I couldn't find a link on it, but at each cell they have found in the US so far (2 i think) there has been rumors (call em rumors cause i can't find the link) rumors that weapons stashes have been found there including ak-47's. One of the terrorist on the run now is supposedly armed and dangerous with a ak-47.

>>Well, the facts just don't back that up. In New York, the vast majority of violent crimes (something like 90%) occur with guns purchased completely legally in other states. Most of the rest occur with guns that were originally purchased legally. It is extremely rare that a criminal gets a gun through some secret ring of weapons dealers.

Where did you get your facts from? My facts say 60 years of gun control in Australia have shown and I quote "Western Australia is now one of the least safest places in the country." Well I guess you can throw NY in there too now.

>>The truth is that gun control works. Encryption laws will work. They won't be perfect, but they will help law enforcement do their jobs (do you really think it hasn't occurred to the FBI or CIA that terrorists might still use strong encryption?)

Well I just proved gun control hasn't worked, if there is a way above/over/around a law, a criminal won't stop and anything to get there. You got to remember, our original oppressors (the English) tried everything they could to throw us back into the stone age from keeping the cotton gin from being imported to gun control. It was our nature to find away around that and eventually through our innovation, become stronger than them.

Going back to what I said in my original comment, encryption backdoors are wrong, the criminals will find a way in somehow. Our best solution isn't putting another door on the encryption fortress, its building a bigger badder bomb to blow it up (more hardware, USAcrypto@home)

--toq

Another point to make is that it simply will not work. You can argue about trading liberty for security, but in this case, you are trading liberty for insecurity.

Congress is talking about putting back doors into cryptography schemes. There is a good Second Amendment argument against this, but some congressmen just don't care about it. So show how it will fail.

First off, we must remember that we are dealing with truly elite terrorists here, not the 31337 ones we have been used to. The attack we just sustained was a work of twisted, despicable genius. Such people will break this law without a thought. If they can't get somebody to sell them crypto without a backdoor, they'll just get it off a .sig file from old USENET postings (strong crypto has been written in four lines of Perl). This won't stop them. It will stop law-abiding citizens.

If there is a back door, this means that the government has a key that would break a given encryption scheme. That's way too many eggs in one basket.

Do you know what that key would fetch on the black market? Do you know what people would do to get it?

Like people in any walk of life, there are law enforcement agents and police officers with crime in their hearts. And one dirty cop with access to a key could make millions selling it.

Even if not, remember a few years ago, distributed crypto key cracking. Someone would encrypt a message using a crypto scheme, and hold a contest to see who could crack it first (thus, this was a "white hat" exercise). So people came up with programs that everybody could run on their computers, so that they had thousands of computers trying bazillions of keys until they got something that worked.

If the Fed required back doors, and I was a cybercriminal that wanted to crack it (perhaps to steal credit card data from online transactions...), I would build a distributed cracker, and marry it to a virus or worm. Infect millions of machines and have them busily cracking the Master Key for me.

Let me suggest that we also brainstorm here for useful laws that Congress could pass. I think that when an event like this occurs, there is tremendous political pressure to do something. Passing laws that won't help the situation, may even hurt the situation, but look like they help will be popular with voters. And if a lone voice turns and says "I won't vote for this because it won't work," they're not likely to get re-elected.