Slashdot Mirror

Well, Distributed.net of course! They've just finished RC5-64, and are continuing on OGR. RC5-72 should start within a month or so.

More cycles for the Optimal Goulomb Ruler search!

What do you think about Distributed.net and other distributed computing projects that utilize the internet? At any point during your work before the mid-90's, did you ever invision such a concept as distributed computing over a worldwide inter-network being a viable alternative to expensive supercomputers?

Building on that last question, did you at any time consider the possibility of Distributed Denial of Service (DDoS) attacks against a single host on the inter-network, or against the inter-network as a whole? If so, what, if any safeguards did you consider implementing to protect against such problems?

The P4 has no unit dedicated to integer rotate, which is a huge step backward from the P3. RC5 relies heavily on rotate.

But, comparing the P3 or K7 to the G4, the G4 still wipes the floor with both. The small number of registers in x86 really hurts here.

Here is a client speeds database.

Here are some Perl scripts that make use of a modified version of Crypt::RC5 to decrypt the RC5-64 solution, the RC5-56 solution, and the RC5-64 false-positive.

http://www1.distributed.net/~bovine/perl-rc5/

Hmmm... as it says here:

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

The vote will be decided on through an extension of the statistics engine, with one vote per block per person.

And to think.. it took a few seconds to find that, and a couple minutes to type your post

No, you can still work on the optimal golomb ruler project (OGR), which is an interesting distributed project that becomes exponentially more difficult for each added mark. Currently they are working on a 25-mark ruler, and verifying the 24-mark ruler. From the linked page: "OGR's have many applications including sensor placements for X-ray crystallography and radio astronomy. Golomb rulers can also play a significant role in combinatorics, coding theory and communications, and Dr. Golomb was one of the first to analyze them for use in these areas."

Don't they teach math anymore?

Based on the numbers from distributed.net. The actual computing power used is equivalent to 32504 800Mhz Apple powerbook G4s running for 676 days. With the same number of powerbooks you could exhaust the keyspace in 790 days. For 100 million dollars USD you could buy 100000 Dell Athlon XPs from BestCry and exhaust the keyspace in a little over a year.

Our peak rate of 270,147,024 kkeys/sec is equivalent to 32,504 800MHz Apple PowerBook G4 laptops or 45,998 2GHz AMD Athlon XP machines

In the interests of speed, only the first "block" of the crypted text is decrypted and evaluated for a solution. This means that it's possible for a key which isn't the correct key to report as a false positive because although it doesn't decrypt the text it does yield a plaintext which matches "The unkn" for the first eight bytes.

There's been much speculation and napkin scribbling on just how frequently such false positives might present themselves. The general consensus seemed to be that such an occurrence is extremely improbable but in a dataset the size of 2**64, extremely improbable may still yield a nonzero frequency.

The key 0xBB27D52F60FD932C does, indeed, decrypt to a plaintext for which the first eight bytes match the known plaintext for the contest. The remainder of the decrypted text, however, is just garbage. This key has actually been returned by clients twice over the course of the contest.

In August 1999, "Edward Scissorhands" turned in the key.

Again in July 2000, Team RC5 Chile submitted it. Since they're unfortunately using a shared email address for their team, there's no way to know which individual was the submitter.

I wasn't the winning key, but was a really unique "near miss". It also represents an interesting datapoint regarding the RC5 algorighim. A brute-force search is really the only way to conclusively determine the liklihood of such false positives.

In the interests of speed, only the first "block" of the crypted text is decrypted and evaluated for a solution. This means that it's possible for a key which isn't the correct key to report as a false positive because although it doesn't decrypt the text it does yield a plaintext which matches "The unkn" for the first eight bytes.

There's been much speculation and napkin scribbling on just how frequently such false positives might present themselves. The general consensus seemed to be that such an occurrence is extremely improbable but in a dataset the size of 2**64, extremely improbable may still yield a nonzero frequency.

The key 0xBB27D52F60FD932C does, indeed, decrypt to a plaintext for which the first eight bytes match the known plaintext for the contest. The remainder of the decrypted text, however, is just garbage. This key has actually been returned by clients twice over the course of the contest.

In August 1999, "Edward Scissorhands" turned in the key.

Again in July 2000, Team RC5 Chile submitted it. Since they're unfortunately using a shared email address for their team, there's no way to know which individual was the submitter.

I wasn't the winning key, but was a really unique "near miss". It also represents an interesting datapoint regarding the RC5 algorighim. A brute-force search is really the only way to conclusively determine the liklihood of such false positives.

Hmmm... as it says here:

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

The vote will be decided on through an extension of the statistics engine, with one vote per block per person.

And to think.. it took a few seconds to find that, and a couple minutes to type your post..

For the first time you can actually watch the owner of a website watch his server crash and burn via a webcam :-)

http://members.slacker.com/~nugget/camb.php

Found via : Distributed Webcams

Link here: http://www.distributed.net/pressroom/news-20020926 .html

The G4 is still a fantastic processor for certain operations, such as cracking so many RC5 keys per seconds...:)

I think a 16 MHz ARM processor would only be in a "high end" smart phone, or a PDA and not your mass market average cell phone.

What would a "mass market average cell phone" need with fast public-key encryption? Can't it just authenticate with the cell tower, grab a symmetric key, and then just encrypt voice with AES[1] based on that, possibly grabbing new symmetric keys during non-talk time? Wouldn't the more advanced "Burning Cell Phones" that run apps other than voice and simple games be essentially PDAs with a fast processor anyway?

Think 8 or 16 bit, less than 12 MHz on average.

So you're talking half the power of a GBA. (The GBA is 32-bit with a 16-bit data bus, clocked at 16 MHz.) How does RSA computation scale with respect to keylength?

[1] Yes, AES been theoretically attacked down to 96-bit, but 96-bit is still considered quite "strong" for symmetric encryption. It has taken nearly four years, and one of the world's biggest clusters still hasn't broken a 64-bit key.

*ahem*

They themselves state that RC5 is a poor overall CPU performance benchmark

"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."

It also helps the G4 quite a bit that they have an Altivec crunching core for RC5, whilst there isn't an SSE cruncher for those of us living in x86 world :)

... they're still doing those encryption-breaking projects!

Yeah but for me to run my dnetc on my powerbook, i have to have it plugged in (no mains power = paused) Ouch! it's hot :)

P2P falls into two categories nowadays, file sharing (FastTrack/Kazaa, Gnutella/Gnucleus-Shareaza-Limewire-Bearshare, Edonkey2000) or publishing (Freenet and Mnet/Mojonation). Like Freenet, Mojonation was more of a publishing network - users publish data, it gets broken into little chunks, encrypted, and then sent out to other computers, and you receive other people's encrypted chunks on your computer making you a "block server". Content trackers and Publication trackers kept track of the meta-data and where the blocks were, and metatrackers kept track of where the trackers (also called brokers) were. I chatted with zooko, one of the developers, on IRC, he was cool and the ideas were very interesting. Like many dot-com stories, it was ahead of it's time in many ways. They converted Mojonation to the open source MNet , whose CVS tree you can peruse. A lot of it is in Python, a language I do not know.

The wasted disk space on workstations (and servers) is something thought about by many, especially in large organizations with large networks. My last company began implementing SANs, so that less disk space would be wasted, and the centralization of disk space allowed for greater redundancy and easier backup. They also ran low priority (nice'd) distributed.net processes across the whole network on non-production machines. You can take a guess about how large the network is by seeing that they're still ranked #22 without submitting any keys for a year.

And what about the people crunching SETI@home or folding@home or distributed.net's challenges? Sure, 3 or 4K may not seem like much, but it adds up, and I imagine there will be a small decrease in the participation in these projects if users feel the need to conserve bandwidth.

Of course, we could start a distributed.net-style company, and try to get ISPs in on it... Have always-on connections offer reduced rates for use of your computer's extra time. That way people could get high-speed connections for less without really sacrificing anything.

That same theory might also make ISPs more lenient about multiple computers on a home connection. (don't know about your cable provider, but mine doesn't like that).

In that case, the real question is "should you shed tears when your 1024-bit PGP key is cracked by distributed.net?"

The problem is the algorithm in developing concurrently-processed chess calculations. The people on D.net couldn't get up enough interest to do the project, and ultimately it never got off the drawing board. Now most of those people have gone on to OGR.

The problem is the algorithm in developing concurrently-processed chess calculations. The people on D.net couldn't get up enough interest to do the project, and ultimately it never got off the drawing board. Now most of those people have gone on to OGR.

After seeing the interest in for example the RC5-56 challenge and others, it is a fact that there is a huge amount of people interested in participating in things like this. Maybe a distributed computing project, willing and open to take any (non criminal) tasks would not be that bad idea afterall. If there would be volunteers for building the crunching code using API provided, it would be possible to run projects with quite short lifecycle. I don't see SETI and RC5-56 and similar projects very interesting anymore. The task should be clear, reasonable and the estimated brute forcing time should be reasonable (like in 3 months maximum.) A dozen of little tasks per year, might prove more interesting.

Anyway, in this particular case, and 99% of others, the password is "IAmGod" :) and in this case probably no distributed brute forcing is needed - just the plain old crackerjack should do. :) .

42 is old. There Earth is pretty small. Here we are talking about something really big. Something like this comes to mind, just on a different scale...

What's with that abnormally low load average?

1) I suppose RC5-64 seeing as that is the one thing i seem to care about at the moment. DAMN, a keyrate of 20.7 M/Keys/sec is faaast. and 48x that in a rack, makes me wish i had much money to blow. DnetcDB

2) Thats a server, woah! They *look* good.Blue PCB inside, sweet metal stylings outside, i know that i should not look at these things and think it is good or anything like that, but i can not help myself.

3) Cooling: This is my only concern, they do not appear to have a decent air intake system at the front of the rack, to cool the internal componantry.Sure the G4 is relatively cool, but there are the HDDs and 48 of them in a stack would be a lot of heat.

4)Comparable to PC offerings. At lest our new racks we are purchasing in the next few weeks are only PIII 1.3G machines, the speed differences of these new apple servers are negligable. To what it used to be

I think that it will be most interesting to see how much penetration into the rack-space market share apple are able to achieve.

1 rack, 42 Xserves, dual G4 1GHz = 42 x 2 x 10,500kkeys/sec
= 8,820,000 kkeys/sec

which would place it 2nd in the top 100 participants for the day, only after The-Space.net @ 12,077,535 kkeys/sec.

Pretty powerful hardware from Apple.

Stats here

I'm pretty sure the iBook has a fan, it just never turns on. My 2 year old 400MHz G3's fan has come on exactly once, when I had it sitting on the bed, probably with the vent blocked. Sitting on a smooth table running RC5 decryption, my processor's internal sensor peaks at 147 degrees F and the fan doesn't turn on. The G3 is particularly power-efficient compared to Intel processors, the G4 less so.

Not necessarily, if Apple can do a good job of optimizing the code to use the G4's Altivec unit, you could end up requiring a much smaller farm.

Although the Altivec is almost ideal for cracking rc5 keys, distributed.net's mulitprocessor client speeds has dual 1GHz G4's processing about four times as much as dual P4 1.8 GHz.

Therefore, allow me to present three proposals that will not prevent copying, but will make it difficult:

• Encypted media - encrypt the media (music, video, etc.) using strong encryption. Do not provide a decryption key in the device. Thus, it will be very difficult for pirates to access the content. A minor side effect is that it will be equally difficult for consumers to access the content. I suspect that this will not present a problem to the entertainment industry. An added benefit, is that it will supply interesting challenges to the folks at Distributed.Net.
• Switch back to analog - CD's and DVD's are digital and thus perfect copies can be made. The industry can simply switch back to VHS tapes and vinyl records. As a bonus, their marketing departments can cite the advantages of the new analog formats and they can charge higher prices for it.
• Mandatory brain implants - the music must be decrypted before it reaches the consumers ears. Similarly, the video must be decrypted before reaching the users eyes. Turn this problem into an opportunity. With mandatory DRM devices implanted into the consumers brain, the entertainment industry can reach new heights of efficiency, productivity, and profit. Just think, if music is playing in a room, only the consumer that is licensed to hear it, will be able to hear it. Other consumers in the room will hear nothing at all. Of course, this solution will require international cooperation - so that eventually, everyone in the world must have a DRM device implanted in their brain. But an industry that created worldwide DVD regions is surely up to this task.

Ok, now all you folks staring at the pretty screensaver really ought to be cracking keys for Distributed.net.

If everyone just jumped on RC5, we'd have the 128-bit key done by now, and ET would still be there waiting for us. If you're going to talk to aliens, shouldn't you at least let them know your computer can brute force a 128-bit encrypted RC5 key? If that doesn't impress them, nothing will. Once they see that, they'll probably show us the secrets of interstellar travel, and eternal life, things like that. But only if we crack keys first, so go download the Dnetc client and get cracking!

all I can think about is how much power the dang thing would consume

I really hope they turn it off during the nights, and run distributed.net clients on their personal computers at home... ;)

<news truth="0">

Mozilla.org has signed a deal with Distributed Computing Technologies Inc. to include encryption research software in the official binary releases of Mozilla 1.0 Release Candidate 5. The RC5 build will include a distributed application to measure the strength of RSA's RC5 cipher, described in RFC 2040.

</news>

Afterall, there's always Extraterrestrial life to search for, encryption to break, or maybe even a cure for cancer. Do we all really need to re-compile rsync?

Wonder how many kkeys/sec it could do on distributed.net

Military-grade encryption has its weaknesses, too. Especially considering it uses "only" 80-bit keys. And ooh dose pesky cwackews!

Good grief.

Give the poor sods a chance to get the distribution ready, please. Perhaps they didn't WANT people downloading it just yet... Hence no announcement, just yet??

Bandwidth and hosting costs money, as poor old distributed.net is finding out. A few mirrors being updated, and then linking to the appropriate announcement would be a bit more considerate than putting up the first submission on the 3.0 release.

If this software utilized any cycles on my system, it will impact performance causing me expense which will rapidly increase to the $5000 threshold (a cumulative threshold).

Not if it's niced down to the lowest priority. I see zero performance impact even on my Windows ME box from running the distributed.net client.

Have you even LOOKED at d.net in the last two years or so? I'd have to guess not, or else you missed OGR, which can be used for exactly the kind of things you're asking for!

Heck, just with crypto breaking you can probably find over a hundred different algorithms that are utilized in breaking crypto only. This way we can get to a thousand in no time, we just need more paranoid developers... ;)

1. Keymaster could be run on a 56k modem, bandwidth-wise. (Although it might be interesting to harness the logic chips of a 56k modem to build a keymaster... hmmmm)
2. There's a very high probability that statsbox-iii would only have to query only a few of the fullservers in order to generate stats for any given user, reducing bandwidth usage, especially if there exists a terse "No data received from that user" reply.
3. Because keys that are out of linear order are ignored, there's a high probability that chunky data (1010101101, where 1 is returned, 0 is not), which is likely produced by an unreliable client, is assigned multiple times. The threshold for reporting could be played with, but I would suggest five as a starting point (fullservers only report streaks of five or more keys within their assigned keyspace that are as yet unchecked).

However, this doesn't reduce the bandwidth at the keymaster any further, since this sort of splitting is already also being done at a larger scale between the keymaster and fullservers (and the bandwidth issue is with the keymaster, not the fullservers).

Getting donations of bandwidth and hosting is harder because those are ongoing commitments (including potential staff-support, and physical colo access, etc).

Direct money donations are also somewhat hard to get. Fortunately distributed.net is a 501(c)(3) organization, which means anyone can donate and receive an income tax writeoff (see articles of incorporation). Tax day is coming up soon, folks! :)

Client downloads are PGP signed http://http.distributed.net/pub/dcti/v2.8015/ and are served by machines that mirror it (via rsync over ssh) from a tightly controlled host, which is not one of the servers that actually publicly serve the files. Although the binaries are pre-compiled, the original source code is open for review at http://www.distributed.net/source/

Client downloads are PGP signed http://http.distributed.net/pub/dcti/v2.8015/ and are served by machines that mirror it (via rsync over ssh) from a tightly controlled host, which is not one of the servers that actually publicly serve the files. Although the binaries are pre-compiled, the original source code is open for review at http://www.distributed.net/source/

FWIW, Our clients actually can speak a pure HTTP protocol for requesting data, allowing a simple /cgi-bin/rc5.cgi script handle direct serving, but the default communications mode is a more compact raw binary mode.

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