Slashdot Mirror

Reminds me of the time i got admin access and cowed my entire college network. moooo...

By "cowed" I assume you mean "installed the distributed.net client on." But cows don't say "moo"; what they do say is closer to "nur."

Heh, I'd just like to see what its Bovine RC5 keyrate is. I mean, an Athlon 1440 can get about 5 Mkeys/sec, so I can only imagine what this beast gets..

Alex Bischoff
---

Heh, I'd just like to see what its Bovine RC5 keyrate is. I mean, an Athlon 1440 can get about 5 Mkeys/sec, so I can only imagine what this beast gets..

Alex Bischoff
---

Heh, I'd just like to see what its Bovine RC5 keyrate is. I mean, an Athlon 1440 can get about 5 Mkeys/sec, so I can only imagine what this beast gets..

Alex Bischoff
---

a CPU spends most of its time doing strictly nothing but wait for the rest of the world.

Indeed .. time to get some RC5 crunching action happening in those spare cycles.

--

And please, no one pull out the stupid integer performance tests and try and tell me 500Mhz PPC = 1Ghz x86!

If you do not want integer tests, how about a number crunching solution, that is perhaps equally optimised on both sides of the fence. How about Distributed.net client?

Some g4 rsults:
Power PC_7400_G4 433 3,903,000
Power PC_7400_G4 450 3,794,467
Power PC_7400_G4 500 4,383,581
Power PC_7400_G4 733 6,529,242


Some intel PIII results:
Intel Pentium III 1000 2,818,393
Intel Pentium III 850 2,379,094
Intel Pentium III 733 2,034,363
Intel Pentium III 500 1,383,202

Some TBird (AMD K7) reults:
AMD K7 Athlon Thunderbird 1200 4,283,940
AMD K7 Athlon Thunderbird 1000 3,549,885
AMD K7 Athlon Thunderbird 850 3,021,021
AMD K7 Athlon Thunderbird 450 1,589,342


I am not trolling, but i am trying to point out that for properly optimised code, you can get decent real world scientific FAST crunching from the G4 processors, even though they operate at 1/2 the clock.


How every version of MICROS~1 Windows(TM) comes to exist.

We are also the only company with clients for Windows, Linux, and Mac.

Get your facts straight, please. For instance, the Distributed.net effort has clients for Acorn RISCOS, AmigaOS, AIX, BeOS, OpenBSD, NetBSD, FreeBSD, BSD/OS, DEC UNIX/OSF1, PC-DOS/MS-DOS, HPUX, Linux, MacOS X, MacOS, Novell NetWare, NeXTStep, IBM OS/2, IBM OS/390, QNX, SCO Unix, SGI IRIX, Sequent DYNIX, SINIX, Solaris/SunOS, DEC VMS, Windows 95/98/NT/200 and Windows 3.x. More clients are under development. So while it is nice to hear that you have support for more than just Windows, please don't believe that you are on top. I bet that SETI@home has clients for more than Windows/Linux/MacOS too.

Oh, and as for sandboxing: at least for Linux, something like User-mode Linux would be an excellent choice.

We already have such a sandbox which is multi-platform (including Linux.) Although it's not the fastest possible implementation, I'd be much more willing to donate my spare computing cycles if the program were written as a Java applet.

The same restrictions that make Java applets safe also, to me, sound like the restrictions that would make distributed computation safe. They have no access to your local disk. They cannot make network connections, except to the source of the code.

Aside that people think of applets only for displaying graphics, and maintaining one of them up 24/7 would be difficult, are there any reasons why Java applets shouldn't be used for distributed computing?

Microsoft delays release of Windows 2000, and the Linux community screams in delight that it must really suck, despite the pretty-damn-stable RC builds

Were the Win2kRC? releases available to the public? (No, I'm not talking about d.net's RC5 brute-forcer either.) The Mac OS 10 beta and Linux 2.4 beta are both OutNow. The 2.4-test releases are betas; this article is about Linux 2.4 RC1.

No wait, every Microsoft operating system release is a public beta.

and SETI is an incredibly worthless disinformation campaign run to keep Earth in the dark about the presence of intelligent life outside of our solar system

And distributed.net is incredibly worthless disinformation campaign run to keep Earth in the dark about the presence of unbreakable strong encryption, correct?

wow. now here is an example of someone not reading the FAQ.

The distributed.net client uses IDLE cpu time. The client runs all the time.

http://www.distributed.net/faq/

please, I've contributed to the FAQ for dnet: read it and learn.

If you don't think RC5 is worth the effort, you can always work on distributed net's Optimal Golomb Ruler project. Solving an OGR does have some practical benefits related to cystallography and astronomy.

There is already a distributed.net worm. More info.
---------------------------

as i have already pointed in my comments before distributed.net has more projects than rc5-64.
you might want to take a look at a optimal golomb ruler project page at d.net.

as i have already pointed in my comments before distributed.net has more projects than rc5-64.
you might want to take a look at a optimal golomb ruler project page at d.net.

Try OGR, the Optimal Golomb Ruler project. Finding better OGRs is actually a lot more clueful than brute-force cracking encryption keys (we've demonstrated that can be done, enough already!) - these interesting mathematical objects actually have many practical applications in comms, radio astronomy (so you are helping to find the LGMs) and other funky areas. And they even make beautiful necklaces....

there is some science now :) check out ogr projects. ogr homepage on distributed.net has more information what ogr is and how it can be used.

there is some science now :) check out ogr projects. ogr homepage on distributed.net has more information what ogr is and how it can be used.

Well. We've been working on the the RC5 64-bit encryption for over three years now and we've only exhausted 37% of the keyspace. There was at one time a point to the RC5-64 project, but now it seems rather pointless. Yes, we broke 56-bit encryption in a day, but can't we just recognize that 64-bit encryption is good enough? Aren't there other, more worthy uses of our spare CPU cycles? Such as, say finding Optimal Golomb Rulers, which is actually a valuable contribution to the mathematic and scientific community.

I believe distributed.net should give up RC5-64. Let's all just swallow our collective pride, forget the prize money, and work together on something useful.

my dnet stats page, for those interested....

-the wunderhorn

Well. We've been working on the the RC5 64-bit encryption for over three years now and we've only exhausted 37% of the keyspace. There was at one time a point to the RC5-64 project, but now it seems rather pointless. Yes, we broke 56-bit encryption in a day, but can't we just recognize that 64-bit encryption is good enough? Aren't there other, more worthy uses of our spare CPU cycles? Such as, say finding Optimal Golomb Rulers, which is actually a valuable contribution to the mathematic and scientific community.

I believe distributed.net should give up RC5-64. Let's all just swallow our collective pride, forget the prize money, and work together on something useful.

my dnet stats page, for those interested....

-the wunderhorn

Well. We've been working on the the RC5 64-bit encryption for over three years now and we've only exhausted 37% of the keyspace. There was at one time a point to the RC5-64 project, but now it seems rather pointless. Yes, we broke 56-bit encryption in a day, but can't we just recognize that 64-bit encryption is good enough? Aren't there other, more worthy uses of our spare CPU cycles? Such as, say finding Optimal Golomb Rulers, which is actually a valuable contribution to the mathematic and scientific community.

I believe distributed.net should give up RC5-64. Let's all just swallow our collective pride, forget the prize money, and work together on something useful.

my dnet stats page, for those interested....

-the wunderhorn

So how about some help?

I mean, what's the point in discovering extraterrestrial life if we can't crack their private key? :)

So how about some help?

I mean, what's the point in discovering extraterrestrial life if we can't crack their private key? :)

Odds of winning Oregon Megabucks (4 out of 6 numbers matched, estimated prize $23.70): 1 in 335 . --Oregon Lottery

The odds are 1 in 496,870 that this participant will find the key before anyone else does. --Distributed.net.

Alright! So I'm more likely to get hit by a deorbiting satellite than winning $25 from the State or finding the winning key to RC5!

--

I know a certain non-profit organization that maintains helluva lot networked computers... :)

-jfedor

• open GZIP, "gzip -dv $workdir$basefn 2> /dev/stdout |";

• open BCP, "bcp import_bcp in $finalfn ... -c -t, 2> /dev/stderr |";

• if(!open SQL, "sqsh ... -i integrate.sql 2> /dev/stdout |") {
  stats::log($project,139,"Error launching sqsh, aborting hourly run.");
  die;
  }

You bring up an interesting point. DCTI, as you have enumerated, has four "core" technologies: RC5, DES, CSC, and OGR. The RC5 stuff started out as genx and eventually became what is now DCTI. (It wasn't DCTI until sometime after genx folded. It was Distributed Computer Processing, or something like that prior to incorporation.) RC5-56 and RC5-64 are the same core. The switch from 56 to 64 was lightning fast -- on the order of days.

DES. To the best of my recollection -- and I was part of d.net then -- no one within DCTI wrote, from scratch, on their own, a DES core. Everything started out with brydDES and a generic "C" core. Later a "bit slicing" core was provided that made a significant difference to some platforms (most notablly, the Alpha.)

CSC. An interesting if little known factoid... It took DCTI an excessively long time to include CSC capabilities to the clients despite having had the source for a CSC core for months. And they later announced they would not be optimizing their CSC core -- translation: they are going to take what they were handed and run. (As I was told, the C code core came from Remi.)

OGR. This was my first "official" involvement with DCTI which eventually brought me into the inner circle (#dcti and the cursed "+o".) I took gasrp (garsp32 as I recall) and made it "core-able" which is to say it could be started and stop from any arbitrary point (well, at a clean stubing point anyway.) That was in late '97 -- the OGR-21 era. It took almost two (2) years and incorporating Greg Hewgill and the entire Golumb Ruler project to begin processing OGR. Granted, it's a different beast, but it shouldn't have taken that long.

DCTI used to be vary good at giving credit where credit is due. However, looking at the current credits page, they seem to have aquired a very selective memory. The only place you find my name is in the ledger despite over a year of contributions as a general coder, porter/builder, proxy op, and even keymaster briefly. (One of the NICs got fried. The new motherboard was never used because nugget refused to replace a dual Pentium 200 (233?) with a single but dual capable PII 300. Nugget's rant about SPS to MPS is bull... you can install NT as MPS on a single processor system and then stick a second processor in there later. It's one of the first questions asked during installation -- video card, keyboard, system type. But I'm not bitter.)

You bring up an interesting point. DCTI, as you have enumerated, has four "core" technologies: RC5, DES, CSC, and OGR. The RC5 stuff started out as genx and eventually became what is now DCTI. (It wasn't DCTI until sometime after genx folded. It was Distributed Computer Processing, or something like that prior to incorporation.) RC5-56 and RC5-64 are the same core. The switch from 56 to 64 was lightning fast -- on the order of days.

DES. To the best of my recollection -- and I was part of d.net then -- no one within DCTI wrote, from scratch, on their own, a DES core. Everything started out with brydDES and a generic "C" core. Later a "bit slicing" core was provided that made a significant difference to some platforms (most notablly, the Alpha.)

CSC. An interesting if little known factoid... It took DCTI an excessively long time to include CSC capabilities to the clients despite having had the source for a CSC core for months. And they later announced they would not be optimizing their CSC core -- translation: they are going to take what they were handed and run. (As I was told, the C code core came from Remi.)

OGR. This was my first "official" involvement with DCTI which eventually brought me into the inner circle (#dcti and the cursed "+o".) I took gasrp (garsp32 as I recall) and made it "core-able" which is to say it could be started and stop from any arbitrary point (well, at a clean stubing point anyway.) That was in late '97 -- the OGR-21 era. It took almost two (2) years and incorporating Greg Hewgill and the entire Golumb Ruler project to begin processing OGR. Granted, it's a different beast, but it shouldn't have taken that long.

DCTI used to be vary good at giving credit where credit is due. However, looking at the current credits page, they seem to have aquired a very selective memory. The only place you find my name is in the ledger despite over a year of contributions as a general coder, porter/builder, proxy op, and even keymaster briefly. (One of the NICs got fried. The new motherboard was never used because nugget refused to replace a dual Pentium 200 (233?) with a single but dual capable PII 300. Nugget's rant about SPS to MPS is bull... you can install NT as MPS on a single processor system and then stick a second processor in there later. It's one of the first questions asked during installation -- video card, keyboard, system type. But I'm not bitter.)

If you go entirely on the MD5 hash, you will get false positives: look at the "birthday problem" to see why. With literally millions of different songs on Napster, there will be many random "collisions" (as they are known in crypto circles).

To put this into better perspective, distributed.net has been trying to find a single 64-bit key for close to three years now and the key rate is up to 121 billion keys per second without success.

Burris

My contribution to the fray: Damn, but the P4 sucked for distributed.net :-)!

the RC5 algorithm uses 32-bit rotate operations, which is part of the hardware instruction set for Intel and AMD chips (and PowerPC chips too).

NP means that a solution to a problem can be checked in polynomial time, making it possible to bruteforce the solution. NP complete means that there is no deterministic algorithm to find such solution in polynomial time. Factoring numbers is approximately O(n^0.5) divides; simply divide the number n that you want to factor by all primes less than or equal to sqrt(n).

With all other variables equal (bus speed, HD speed, etc.), a 500 MHz PowerPC G3 is approximately twice as fast as a 1 GHz Intel PII/P!!! at doing hard-core integer number crunching (Photoshop, some 3D games in software mode, d.net) according to the SPEC integer math benchmark. And the vector unit in G4 is quite a bit easier to code for than the vector unit in PIII, giving even more speed and boosting Team Slashdot's RC5 rating.
<O
( \
XPlay Tetris On Drugs!

With all other variables equal (bus speed, HD speed, etc.), a 500 MHz PowerPC G3 is approximately twice as fast as a 1 GHz Intel PII/P!!! at doing hard-core integer number crunching (Photoshop, some 3D games in software mode, d.net) according to the SPEC integer math benchmark. And the vector unit in G4 is quite a bit easier to code for than the vector unit in PIII, giving even more speed and boosting Team Slashdot's RC5 rating.
<O
( \
XPlay Tetris On Drugs!

Any predictions on how long it will take someone to crack this encryption method?

You can sure bet people will start trying!

Perhaps it will be a future project for distributed.net?

It's just that ManicDeity called it a 'Napster for Scientists', Hemos likened it to 'Internet2', but it seems it's more like distributed.net . Sorry about that, I forgot to read the article before posting - but I'm sure I heard of something like this a few months (even a year) ago. Any1 else?
Richy C.
--

sdk that is used for this project is cosm. cosm was developed by former distributed.net developer. you can find more info on cosm on http://www.mithral.com/projects/cosm//A

After all, cracking his cipher is obviously circumventing Poe's access-control device!

Encryption challenges sponsored by a cryptosystem designer (such as Poe Cipher and the various d.net challenges) imply a license to take part in the challenge.

Whilst projects like distributed.net and Seti@Home have clocked up shocking amounts of processor time (410497.11 years on Seti@Home), they're still running on the 'cool factor' of having your machine break codes or search for aliens.

Sites such as ProcessTree, and others, have been talking of paying for your computer time with micropayments, but so far nothing seems to have got off the ground.

Presumably with the added incentive of cash, the number of computers taking part will rocket. Does anyone have any firm information on the progress of these schemes?

As the king of my own mini-geek house, I tend to agree. Geeks have this savage territoriality that is almost second nature; akin to the Geek Drinks like those at ThinkGeek.com, a geek's dominant presence must be felt from your first sip all the way to the bottom of the can, when you get annoyed and toss the empty shell aside.

Cheesy metaphors aside, I have a 4 bedroom (well, 3.5 really) house amateurishly wired up for local network mayhem. Though the WAN is a mere 500Kb/s cable modem connection, I've found it more than sufficient to run the (mostly 486 & pentium) 10 machines that are pretty much only active to run Distributed.net's little cow TSR, or rack up points for my Echo.com internet radio rewards account.

Allow me to (briefly) beat my chest: the cable modem is hooked directly to a 1-port router, then through an 8-port 10/100TX switch to various parts of the house. 4-port hubs are strategically located in certain spots (2 rooms I call "my own," for instance), and if I manage to work up the nerve, I will eventually run a line to the last part of the house that isn't wired other than the garage: the "grandmother" unit attached to the front area.

Now, my amateurish question of the day: since I already have a Cable/DSL router acting as a gateway of sorts, is it worth the trouble to stick a Redhat/Apache machine in between it and the rest of the network to act as a firewall and web server?

--

We're currently processing, simultaneously, RC5-64, OGR-24, and OGR-25 work.

Plus, we've got about a quarter of a million machines, not 100,000. :)

We're currently processing, simultaneously, RC5-64, OGR-24, and OGR-25 work.

Plus, we've got about a quarter of a million machines, not 100,000. :)

We're currently processing, simultaneously, RC5-64, OGR-24, and OGR-25 work.

Plus, we've got about a quarter of a million machines, not 100,000. :)

Howerver, it seems unlikely that a method for distributing trusted open-source clients will ever be developed. Jeff Lawson, the chief architect of the distributed.net software has written a white paper discussing the various techniques which may be employed when trying to verify the validity of work performed on untrusted machines. You can read it here.

At distributed.net, we release as much of the source code as possible, but compromise at obfuscating the function of the networking and file-handling code. In this way, we make tampering with the clients more difficult.

While we recognize that not releasing all the source and relying on binary-only clients still doesn't completely eliminate the possibility of sabotage, we feel it is a beneficial contribution to our overall security implementation.

Howerver, it seems unlikely that a method for distributing trusted open-source clients will ever be developed. Jeff Lawson, the chief architect of the distributed.net software has written a white paper discussing the various techniques which may be employed when trying to verify the validity of work performed on untrusted machines. You can read it here.

At distributed.net, we release as much of the source code as possible, but compromise at obfuscating the function of the networking and file-handling code. In this way, we make tampering with the clients more difficult.

While we recognize that not releasing all the source and relying on binary-only clients still doesn't completely eliminate the possibility of sabotage, we feel it is a beneficial contribution to our overall security implementation.

This is on both the d.net and SETI FAQ lists. Such clients transfer small (<300 KB) chunks of data during (say) your wife's e-mail check.
<O
( \
XGNOME vs. KDE: the game!

...but not in a FREE SOFTWARE® way. For example, distributed.net releases the source to its computing cores; asm wizards have optimized the cores to run on AltiVec, 3DNOW!, etc. However, only d.net's trusted binaries connect to the official servers.
<O
( \
XGNOME vs. KDE: the game!

DCTI does release the source for d.net test clients (so that all the hot-shot asm coders can improve the cores), but test clients don't connect to the d.net servers. Only trusted binaries connect to the servers.
<O
( \
XGNOME vs. KDE: the game!

DCTI does release the source for d.net test clients (so that all the hot-shot asm coders can improve the cores), but test clients don't connect to the d.net servers. Only trusted binaries connect to the servers.
<O
( \
XGNOME vs. KDE: the game!