Slashdot Mirror

Just took a look at my stats on distributed.net this morning, and something definately looks screwed over there. Yesterdays stats for the Slashdot team look somewhat strange too :-)

Just took a look at my stats on distributed.net this morning, and something definately looks screwed over there. Yesterdays stats for the Slashdot team look somewhat strange too :-)

Just took a look at my stats on distributed.net this morning, and something definately looks screwed over there. Yesterdays stats for the Slashdot team look somewhat strange too :-)

So, take the time to learn Dvorak. ... it should effectively screw up any timing-based password sniffers!

Not so fast. The choice of Dvorak or QWERTY adds only one bit of entropy, merely doubling the possible dictionary/brute-force keyspace to check. This poses no problem to attackers whose computer power increases exponentially with time. (I wonder why distributed.net 's keyrate appears to increase linearly though...)

I know the problem is theoretical, but when people were talking about breaking encryption (rsa for instance) originally, they said it would take quadrillions of computing years. Now in the era of fast(er) computers, and (distributed networking models), keys are easier to break. Were the original people who made the 'practically unbreakable' claims thinking of today? Obviously not, because it wasn't a quadrillion years ago that the original claims were made.

-yb

I know the problem is theoretical, but when people were talking about breaking encryption (rsa for instance) originally, they said it would take quadrillions of computing years. Now in the era of fast(er) computers, and (distributed networking models), keys are easier to break. Were the original people who made the 'practically unbreakable' claims thinking of today? Obviously not, because it wasn't a quadrillion years ago that the original claims were made.

-yb

Don't forget the most inmportant benchmark of all:

RC5

The G4 clearly wins that race. Since I don't do much image processing... and the G4 and Athlon are about the same in terms of compiling code... I would go G4.

Now if only I would buy a G4 for $200 and a motherboard for $100... :-)

since Slashcode is GPL software, all it would take is an examination of the source code

Slashcode as distributed on slashcode.com is free software and is distributed with source code. OTOH, Slashcode as used on slashdot.org is free software, but it is not distributed in any form[1]. Not distributing binaries == not required to distribute source code.

[1] I'm not counting distributed computing. "Distribution" according to the GPL refers to transfer of software to another entity, not running the code on multiple load-balanced servers, as Slashdot does.

The article was indeed preaching the glories of Linux. That's fine, however it's done using half truths (that's half lies for the pessimists among us) instead of the actual great benefits. Some examples:

"If Largo ran Windows 2000 as a server operating system, Dave says they'd have to run "a substantial server cluster" instead of a single machine, because "NT [or 2000] gets flaky when you run more than 40 clients, while Linux can handle hundreds." Dave has no exact figure for the cost of of an adequate Windows server array for Largo's civic needs; it was obviously so much more expensive than the Linux alternative that it was never seriously considered."

Half true. I've been using DOS/Windows for years... these guys were running SCO back in 1992. Linux is an understandable (and smart) upgrade path for them, it's familiar and it's compatible. More importantly, they were already familiar with it. However their comparisons to Windows based solutions make me wonder - being relatively new to Linux I'm sure I'd assume things fed to me by popular culture or the media if I was trying to plan a comparable solution. They're right about cost - a Windows based solution to do the same thing is rediculously expensive. It's not however terminally buggy. I personally run Windows 2000 Pro on all but one of my computers - they don't crash... ever. Neither do our NT4 or 2000 servers at work (all 6 of them). Then again, neither does my Linux box.

If they wanted to run a Terminal Services environment under 2000 with MetaFrame (for sound, true color, etc.) they could pull it off on that same server - with the same thin clients. This document (MS word... sorry) discusses Terminal Services capacity planning - you might want to look here for a rough comparison between the processor speeds in the whitepaper and those used in the article (a few quick calculations show a P-III 933 to be about twice as fast as a P-III 450, of course these are highly subjective benchmarks). Needless to say, they should be clustering under either OS for redundancy, not because of an hypothetically unstable configuration. Server crashes, whether Linux or Windows, generally involve rebooting or restarting services. However what happens when your hardware fails on the single machine supporting 800 users?

"Their 10-person IT staff supports 800 users running 400 devices (as Dave calls the thin clients). There is no way they could adequately support that many users and devices with such a small staff if they ran Windows on individual desktops. Dave says that if they had gone that route, "We'd be doing nothing but running around fixing PCs all day."

This is absolutely rediculous. We have 2 people (and 2 more who spend about 5 hours a week each doing IS work) dedicated to supporting about 175 users in 3 offices, all running Windows PCs, mostly 98. Our servers almost universally run NT4. Management hasn't had a single complaint in over 4 months. Email, websites, printers, etc. run without a hitch. If we wanted to make our lives easier - we could always deploy Windows 2000 and deny local administrator to the user of the PC. So long webshots!

Don't get me wrong - I don't have a problem with Linux. We use it at work for our firewalls, because of the low hardware requirements and the complete superiority of IPChains over MS Proxy server at the time we made the decision. I use it at home for my second PC because I want to learn more about it. However I do have a problem when an OS is touted as the only reasonable solution - when it's not. Linux may be the best way to go for these guys, if so please tell us the real reasons, like the cost benefits (familiarity, lower initial cost, etc).

My 2 cents.

Someone hook all this shit up to dnetc! Talk about a kickass keyrate..

* d.net rc5-64

Well, try this one then. d.net has a comprehensive list of client speeds. Let's have a look at what they have to say..

How do you like that benchmark?

There are plenty of cross platform apps which can potentially be used for benchmarking both PPC and x86 computers. Here's a short list:

...
* d.net rc5-64
...

From the distributed.net client speed page:

• PPC G4 500 MHz 4.4 Mk/s
• AMD Athlon 1000 MHz 3.5 Mk/s
• Intel P4 1700 MHz 2.4 Mk/s

I guess we've settled the issue of Mhz vs. performance once and for all. ;-)

For those of you who are not donating your clock cycles to seti@home, you might want to try distributed.net. Right now, they are working on cracking a 64bit encryption key, which is also a contest from RSA securities. They are also working on finding more Optimal Golomb Rulers, so it seems that trying to factor this really huge number would be a nice fit. Take a look at the RC5 stats here. They are nifty.

It may be problematic insomuch as they are already working on three projects, and spliting off into another project would be troublesome. But, there are no other serious efforts going on towards these types of projects, so I suppose us d.net fans will just have to wait and see.

For those of you who are not donating your clock cycles to seti@home, you might want to try distributed.net. Right now, they are working on cracking a 64bit encryption key, which is also a contest from RSA securities. They are also working on finding more Optimal Golomb Rulers, so it seems that trying to factor this really huge number would be a nice fit. Take a look at the RC5 stats here. They are nifty.

It may be problematic insomuch as they are already working on three projects, and spliting off into another project would be troublesome. But, there are no other serious efforts going on towards these types of projects, so I suppose us d.net fans will just have to wait and see.

For those of you who are not donating your clock cycles to seti@home, you might want to try distributed.net. Right now, they are working on cracking a 64bit encryption key, which is also a contest from RSA securities. They are also working on finding more Optimal Golomb Rulers, so it seems that trying to factor this really huge number would be a nice fit. Take a look at the RC5 stats here. They are nifty.

It may be problematic insomuch as they are already working on three projects, and spliting off into another project would be troublesome. But, there are no other serious efforts going on towards these types of projects, so I suppose us d.net fans will just have to wait and see.

For those of you who are not donating your clock cycles to seti@home, you might want to try distributed.net. Right now, they are working on cracking a 64bit encryption key, which is also a contest from RSA securities. They are also working on finding more Optimal Golomb Rulers, so it seems that trying to factor this really huge number would be a nice fit. Take a look at the RC5 stats here. They are nifty.

It may be problematic insomuch as they are already working on three projects, and spliting off into another project would be troublesome. But, there are no other serious efforts going on towards these types of projects, so I suppose us d.net fans will just have to wait and see.

If you can see it, then you can copy it. Time-Warner, Fox, and other broadcasting corporations need to figure this out. Then they could stop wasting millions on encryption and give us show we like. If people can break CSS and 56 bit RSA encrytpion, then I think anything the media tries to do is futile.

D/\ Gooberguy

Yes, you DO need permission to run the client on computers/networks/etc not owned by you. As stated in theOfficial distributed.net policies.

I ran into this same problem about 3 years ago. I was running a d.net client on my school's DNS server. Well at the time I didn't know it was the DNS. (Hey, the school gave us accounts to play around with for our Unix class.) I ended up causing a massive network slow down for about a week. Granted the DNS was ancient piece of crap, but it was working fine until I got a hold of it ;). I guess I should also note that I had the nice'd the client to run at top priority effectively slowing all other services down. Ooops. I learned my lesson that day when the Sys Adim grabbed me in the parking lot after class and told me to take the client off the server. Since I was a student (and didn't know I was causing problems campus wide) they were not going to punish me in anyway. I was lucky. I also should have read the Terms of Use before I went Gun-Ho and installed the client.

We are blind to the Worlds within us

I am the network admin here at Avonside Girls' High School in Christchurch, New Zealand.
Here's our RC5 ranking
I could be in the same sort of position as this gentleman, having done 13M blocks in 2 1/2 years in this job. My only difference is that we were on a flat-rate internet connection at the time I started.

It's real.

Any browser that show the ALT text when the pointer is hovered over images will show you that he registered on AT forums in Oct '99 when they were created. Also, read the thread. One member named Russ has already contacted the attorney's office and has offered help. In case you didn't know, Russ is the maintainer of the TA Cube account, which is seventh overall in in the RC5 contest. Russ is very involved in RC5, and I would assume he knows what he's talking about. Finally, read the guy's RC5 stats. Note that he's 94th overall but his current keyrate is only about 1000 kkeys/s compared to his overall of over 55,000. The PCs he lost are probably the ones he's being sued over. I don't think this is a hoax at all.

Sorry if a strong opinion trips your internal troll alert. YHBT in that case.

Anyway, if he wins the rc5 contest, he will get $2000 (or 1k if he is on a team...). Plus the increase in lateral penile dimensions coming from all of those keys he was crunching. Installing the client on a boatload of State owned computers to increase his keyrate and chances of finding the winning key is wrong. He does not own those computers and he had no business installing the client on them.

Distributed.net has a clear policy that says that they will not tolerate this shit either. All of the keys cracked on those machines, as well as the ones cracked legitimatly on his own machine will no longer be credited to him.

You are right, however, in that he is not in the same category as kiddie porn freaks or pirates. He deserves a FAIR penalty which I think I said in my original post. (Checking back I see that I said appropriate).

It's sad that I get branded a troll by people because my opinion is unpopular.

I wonder how this will affect distributed.net's overall keyrate. I'll bet there are tons of clients installed on school/work machines without permission. When word of this gets out it'll scare a lot of people enough to remove any traces of the client.

I am absolutely amazed that employers do not use the power of their idle PCs THEMSELVES!

There are so many applications out there already - SETI@home being one, others include a few at distributed.net, FightAids@Home.org, and there are others cropping up, supporting cancer research, some commercial projects, code-cracking. Many many popular (in a geeky or tear-jerky way) projects that interest us enough to donate our unused cycles.

Now, a company such as TVA - that would rather its employees does NOT use their cycles for such tasks - would do well to provide some other diversion to occupy the screens of its employees. Hey, they could even license the software from SETI, Entropia, or some other vendor of distributed computing solutions, tart it up to look nice with their logo, and plug in some of their own research models. I'm sure their scientists have some energy calculations that could benefit from massively parallel computing.

And what of the rest of the world's processors? In a large customer service department in any medium-large sized company - even one with no real scientific research needs - there will be many PCs available for many hours. It would be a simple matter for such a company to rent out its spare cycles, again using the same software, with suitable logos. Except this time it would be managed internally, with no risk of external network corruption. The information server could be housed safely with the rest of the company's servers, making a quiet buck in the background, with everyone happy.

Ah, but that would be too sensible, wouldn't it?

/prak
--
We may be human, but we're still animals.

Heh. The advantages of being a university sysadmin: http://stats.distributed.net/rc5/psummary.php3?id= 73053

Did you miss out on the Dotcom Bubble

> http://stats.distributed.net/rc5-64/psummary.php3? id=226692

Um,
http://stats.distributed.net/rc5-64/psummary.php3? id=79812

Read Operational Code Authentication before you start ranting that it's not the complete source.

Leto
(ivo at distributed.net)

Read Operational Code Authentication before you start ranting that it's not the complete source.

Leto
(ivo at distributed.net)

... could we please get back to work and use all
that power on something meaningfull, such as finding mersenne primes or Optimal Golomb Rulers.

RSA wanted to prove that neither 56 bit and 64 bit encryption isn't enough and that it is possible for a small crack senstive information protected by 56 or 64 bit encryption.

It will take som time to finish the 64-bit RC5 challenge, but it can be done.

Question is should it be finished? Not in my oppinion! Sure they will win $10.000, but that's about the only positive I can see in this. Used wast amount of power and computing time in doing so, only to give RSA reason to sell 128-bit RC5 and argue that it really is secure.

Wote with your CPU power and switch to something we all can benefit from. Larger primes and OGRs are candidates, but I'm sure there are others.

Yes, but then so do all the clients involved in distributed.net, but the system is designed so that the overhead of communication and synchronisation is kept to a minimum.

Now can we get a distributed.net client built for this soon? I mean with all these internet appliances, we could at least maybe generate some prime numbers in our spare time! :)
Sam
--
"The Son of God became a man to enable man to become sons of God."

If it 'only' takes a thousand Pentiums (Pentium 133? Pentium 1GHz?) around ten years to crack their 128-bit algorithm, it's one lousy algorithm that doesn't use all 128-bits of entropy.

A custom hardware design is very effective compared to a conventional attack (as aptly demonstrated by EFF and distributed.net in the RSA DES contests). However, it doesn't matter how fast your chip is if you use long enough keys (and >=128-bit keys are long enough). Try to do the math: even if testing a huge 10^12 keys per second (or more) it will take a long time to bruteforce a 128-bit key.

Basically all algorithms used today are 'strong', or rather, believed to be strong. This includes DES, Blowfish, RC4, RC5, IDEA, CAST etc. This means that it is only their key length that decides how hard it is to crack. Viewed in this light DES' 56-bit isn't enough. RC4 used with a small 40-bit or 56-bit is also vulnerable. Even so, the DES and RC4 algorithms themselves are strong. This is why it is feasible to bruteforce DES with a custom VLSI chip design: the key is simply to short. Doing a bruteforce on a strong 128-bit algorithm is futile whether doing a hardware or software-based attack.

Take a look at the RC5-64 challenge. The key is "only" 64 bits. According to www.distributed.net, the computing power on RC5 is about 160000 PII 266Mhz working 24/7. d.net RC5-64 effort has been running since 1997 and it has not yet exhausted 50% of the keyspace. 128 bits encryption would be 2**64 times harder than RC5-64. That's a lot more!

This is why I believe 128 bit encryption is not crackable with today's technology. We would need a serious breakthrough in computer technology to crack 128 bits. 128 bits encryption might be secure for a couple of centuries even taking into account Moore's law.

Don't underestimate the power of numbers.

I concur.

What I really want to know is what the point of this puzzle is. With SETI@Home, we know the odds are poor, but there is at least some noble purpose. With RC5-64, there may not be much real point (after all - we know it can eventually be broken) but the power of massively parallel efforts for code breaking is further demonstrated. With the Golomb Ruler task, the computing power is going to an immediately useful task.

So, someone tell me, why do I want to waste cycles promoting someone else's movie???

I concur.

What I really want to know is what the point of this puzzle is. With SETI@Home, we know the odds are poor, but there is at least some noble purpose. With RC5-64, there may not be much real point (after all - we know it can eventually be broken) but the power of massively parallel efforts for code breaking is further demonstrated. With the Golomb Ruler task, the computing power is going to an immediately useful task.

So, someone tell me, why do I want to waste cycles promoting someone else's movie???

• Distributed.Net, OGR project: Our current combined OGR network speed is 182.49 Giga-nodes per second
• UD Cancer Research Project: 609,178 devices, 104,791,203 hours total CPU time
• Seti@home: 3044035 users, 673412.833 years of computer time

• restricted access to the communication medium
• the need to filter out the relevant communication from a huge mass of communications taking place at the same time."

...if you're not running the client, do. If you are running the client and you're not affiliated with any other team, please join team Slashdot.org, if for no other reason than to spite these twits, who are ahead in daily counts these days (from their team page: "The best people. The best effort. The best platform. RC5 will fall again....")

--

...if you're not running the client, do. If you are running the client and you're not affiliated with any other team, please join team Slashdot.org, if for no other reason than to spite these twits, who are ahead in daily counts these days (from their team page: "The best people. The best effort. The best platform. RC5 will fall again....")

--

Is overclocking good to do?

Overclocking has been known to cause your machine to become more unstable, more prone to crashing, produce greater heat, and shorten the life of your processor. Furthermore, it is known to cause programs to unreliably execute code correctly, resulting in occasionally incorrect calculations. This includes the functioning of the distributed.net client.
(Remember that even one miscomputed key within a block, that happened to contain the key we are looking for, can ruin the entire project and invalidate the work of the hundreds of thousands of other participants if an entire re-check must be done.)

There are plenty of themes available for Blackbox. >:)

I used to use KDE, and I really liked it. But then I upgraded to 2.1, and was bombarded by such a plethora of useless proccessor time-consuming shit (i.e., the whole blue theme, all the stupid event sounds, etc) that I immediatly started looking for another window manager. Just because I have a high powered computer does not mean that I want to waste it's cycles on a bloated desktop. So then I found blackbox. The binary size is about 1/25 of KDE's, and it is FAST and allows for extreme custimization (hence the myraid of themes available for it) and eye candy, without taking up much processor time. Now I can devote it to something usefull, like cracking RC5 :).
--

The client uploads and downloads blocks of possible keys to and from a central keyserver - and the "reported" blocks have your email address attached to them. So when the PC's/Laptops were stolen, they contacted Distributed.net, who went through the keyserver logs and found the IP address of the stolen computer. This information was turned over to authorities and the stolen computers were traced to the thieves and returned to their rightful owner(s). I am unaware of whether the distributed.net client(s) were CLI or GUI, or if they were running in "hidden mode". If in hidden mode they'd be invisible to the thief.

It's an interesting (and free) solution to finding stolen laptops... well... as long as the thief goes out onto the internet before wiping the hard drive.. but how many thieves are that saavy?

I've used a dual prosessor system for a while, and love it. I never have to experience the jerkiness of a computer in the grips of that slow all-CPU-consuming task not behaving correctly.
My question is, how will the P4's increased bandwith-usage/demand affect an SMP-system?

If performance critical applications drive CPU power above its artificially low 54.7 watt limit, the CPU is halted with a 50% duty cycle (alternating 2 microseconds on; 2 microseconds off) until it cools down. This effectively turns your 1.5GHz processor into a 750MHz processor - just at the moment you demand peak performance.
The way I see this is that you will have peak performance for a while before the CPU slows down. The way most people uses their computer, this should be OK, since they only need peak performance in short bursts.
However, for heavy scientific computations the P4 will effectively run at closer to half speed as the article expresses. And not to forget, running the Distributed.net client or similar will have the same effect! I, for one, could not live with that. ;-)

My second question is, if AMD's prosessor can run fine comsuming 73 watt and P4 will consume 72.9 watt at max speed, why does the P4 need this cooling procedure? Is the P4 smaller and thus hotter?

Fine. I don't think the code should be released either. But they damn well ought to test it, see how long cracks take under various real world conditions, and publish the results. If it's under an hour, businesses should throw 802.11b out the window immediately. But if it takes a week of constant sniffing, personally I'd be more worried about black hats posing as janitors or some such.

Sure, I agree that WEP is weak. But all security is relative. Any prime-number-based encryption can be broken with sufficient cycles. So tell me Mr Owl, how many licks does it take to get to the center of 802.11b?

If you are asking why the THINK code is not available...

The primary reason that United Devices does not release the source code to the THINK application is because it is not our code to release. The THINK application is the brainchild of Keith Davies of Treweren Consultants Ltd. and has been developed with the possibility of being released as a commercial product. In acknowledgement of the non-profit motives of the Intel-United Devices Cancer Research Project and in return for the valuable feedback provided by such a massive deployment, Treweren has allowed the use of their code for this project.

If you are asking why none of the code is available...

Perhaps the most comprehensive treatment of this issue is the opecodeauth white paper written by distributed.net's Jeff Lawson (also a United Devices employee). As most are aware, distributed.net only releases 99% of its code, and withholds the critical protocol and buffer format code as a supplement to the security of the system. Until someone solves the dilemma of trusting work performed by an untrusted machine, obscurity will always be a desirable component of any internet-based distributed computing effort.

In the absence of open source, United Devices is relying on other factors to influence the internet community to trust its motives. In the general sense, we hope that the combined SETI@home and distributed.net pedigree might encourage you to trust that we're doing things the right way. In the more specific sense of the Intel-United Devices Cancer Research Project, we trust that the endorsement and support of our partners speaks volumes on the integrity of this project.

The bottom line is, there are a great number of indicators which you should use to evaluate the integrity and sincerity of an organization, for-profit or not. While open source is a virtually unassailable endorsement, it is not the only tool at your disposal as you try to detect if UD is trying to do something illicit. Heck, perhaps it's naive of me, but I like to think that my presence and attention in this forum (and my leet, low user ID #) supplement UD's image in some small, geeky, inconsequential way.

As to your rephrasing of today's exchange on slashdot, I must respectfully disagree. Michael's comments in the article body were far more inflammatory than your simple condensation indicates. Moreover, there was no justification or corroboration for the claims that UD was poised to violate the trust and agreements contained in the description of the project as provided by both Intel and United Devices. The license on the UD software is nothing noteworthy, and is the normal fare for any organization trying to conduct business with the benefit of legal input. I think it's quite clear that Michael's opinion of the project existed prior to his creative and conspiratorial interpretation of the license agreement.

I also think that my response can be more accurately summarized as "No, no, UD can certainly be trusted because it has done nothing to invoke suspicion. Moreover, its founders and core staff have established a respectable reputation and history in the net community, and within slashdot as well, both in the form of distributed.net and SETI@home. If you're going to accuse United Devices of ill intent, you should be prepared to back those accusations with something more substantive than 'it is possible that they are bad'".

You may feel that my response did "little or nothing to address [the questions raised]", but I would argue that my previous response, as well as this one, not to mention the FAQ and information published in relation to this project have provided considerably more supporting evidence and information that we've seen provided by michael to substantiate his accusations in this article. It's hard to provide less support than the "none" that he was satisfied with providing.

Thanks for the opportunity to respond, and for the lucid response to my earlier post.

distributed.net has 95% of their clients as open source.

Correction: All your CPU cycles are belong to obscure corporations...

Seriously...logic dictates that you must use availible ressources as efficiently as possible to attain the most probable goal. What are the probabilities of finding alien life within the next 6 months? Ok...now after you've spent time figuring that out: What are the possibilities of breaking an RC5 key within the next 6 months?...

Insert shameless advertising: http://www.distributed.net/

Wasn't the whole rationale of the distributed.net project to develop a distributed computing client? I don't think it's hypocritical to attack this falsely-philanthropic company, since they don't have anything to do with the RC5-DES project. I mean, the crypto breaking thing is nice, but their mission statement says nothing about crypto or non-profitness. Distributed.net has a distributed computing client for twenty or thirty different operating systems.

This article at distributed.net DISTRIBUTED.NET AND UNITED DEVICES JOIN FORCES tells how most of the distributed.net team are now working for United Devices. Not necessarily a bad thing, depending on the scope of UD's future projects. I'm all for a simple distributed client that can handle multiple projects - as long as you can elect which ones you take part in. I'll give United Devices the benefit of the doubt for now.