Slashdot Mirror
Dcypher.net Linux Clients Available
Steve Porter writes "Dcypher.net has released MMX-only Linux clients for its CSC Contest. Full information is available at dcypher.net. Non-MMX Linux clients will be available shortly and will feature an improved non-MMX integer core. We would like to take this opportunity to welcome those who will join us, and would also like to apologize for the delay in releasing the Linux clients. FreeBsd clients and proxies will be out shortly."
Is either team using a method where they don't crack whole blocks at once, and only those blocks?
It'd get messy to crack a block of keys, and about half as many again that were scattered across the keyspace, yet happened to be helped by using information from the cracking of the primary key block. So it seems likely that both projects sacrifice the theoretical gains you could get from running the project on one big computer, by only attempting keys in a linear block.
So, the specifics of their optimizations shouldn't prevent them from saying "We use blocks of N keys long, and we'll allocate from 0xffff... down and you allocate from 0x0000... up, and we'll meet in the middle..."
If you have specifics that show otherwise, I'd love to see them.
well, actually im not in the least afraid of any one reading my mind - i have a free, open mind and i dont care who reads it.
What i am concerned about however is the fact that i have to install some binary chunk of code inside my firewalled,secured network that sends some arbitrary unintelligible data though the firewall systems.
Its the integrity of corporate security im takling about here.
This strict view probably does not apply to most educational institutions or installations without sensitive data/traffic.
Why Backups? - All my data gets stored at Echelon...
--
Jor
Actually they are sending your GPS coordinates to the black UN helicopters so they can beam thought-control rays into your brain.
I recommend you put on your tin foil hat to prevent that.
While distributed.net isn't exactly open source, either, at least they play as fair as possible and give you nearly the full source with all of the key routines.
DCTI publishes only a fraction of the source code. The only part they let the general public see is the "cores" -- the part at the heart of the client doing the actual project/contest work. There's a boat load of other source code that comprises the network layer, the buffer handling, and (the part they must protect to the death) the block encryption. Out of the entire tree, only two files must be hidden from the public.
Again, I'm surprised this amazingly weak method of protection has held for soo long. As my dad says, "Locks are to keep the honest people out."
Jor, Well I sure hope you don't use netscape, or an ftp package, or ANYTHING that you didn't write yourself because it may be smuggling data from your system to other system all over the world without your knowledge. Now sorry if that sounded a bit extreme, but that what it looks like from an outsiders perspective. I mean do you run any software that you don't have ALL the source code for (and that you have analized all the source code for). I mean really, look at that size of a dcypher.net packet. It's not large enough to smuggle out a config file, let alone some valuable binary.
The distributed.net network is currently crunching keys 8 times faster than dcypher.
/. advocating the use of a particular program even though it's demonstrably substandard, just because a majority of the ignorant masses are using it.
That's because the distributed.net network currently has over 15 times as many computers working on it than dcypher.net. (Compare here and here; I compared the number of clients which reported in the last day, since I figure that's the most relevent number to compare to current keyrate.) Furthmore, I'd guess that since dcypher.net is so new, distributed has an even higher proportion of the big-iron/large subnets working for it.
I waited, patiently, for over 6 months for distributed to come out with a new project--and when they release OGR, I'll probably come back. But after seeing my dismal keyrate running their CSC core, I decided to give dcypher.net a try.
On my machine (PII-350), the dcypher.net client is roughly 250% faster than distributed's CSC core. It's CSC keyrate is even about 10% faster than my rc-5 keyrate was with distributed.
Furthermore, their stats engine updates in real time, instead of distributed's absurd daily updates during which stats are completely down for an hour and a half. While both web sites are pretty poorly designed, distributed.net has been at times nearly unnavigable (this is getting a bit better).
But the important thing is, dcypher has accomplished all this and they've been around for a month! I can't imagine how you guys can complain about the fact that it took dcypher an extra 3 weeks to come out with a Linux client when it's taken distributed, a much larger organization with presumably much larger resources, months and months to build any clients at all for CSC or OGR (and the one they came up with is infernally slow).
At the time of this writing, d.net is the only network which seems to be able to solve this contest in time (remember that CSC is time-limited, any solution found after March 17, 2000 is void).
Obviously, that's just because 15 times as many people are going with the much more poorly coded, less efficient solution. It's more than a bit ironic to find people on
What's worse is that distributed takes the position that since they have so many loyal lemmings, they can release an unoptimized core and it won't matter because enough people will still run it. It's that arrogant attitude that turned me (and, I'd guess, many others) off of SETI@home.
Oh well; to each his own. Happy cracking!
What money did the initiative earn? You don't get a cent for a key that doesn't match.
As to the one who happens to find the right key - tough luck for the rest of you. Why would that person have to accept your vote on where the money his computer earned by finding the RIGHT key should go? Have we reached communism yet?
IMHO whoever finds the key gets the money. If they want to give something back to the effort or some charity of THEIR chosing, fine. If not they can share it with the INS to the full extend.
I don't expect lottery winners to share their wealth with a charity all lottery players voted for, either.
(Note to Nugget: no one listens to AC's)
(Note to reader: Nugget is not a "coder". He's said this himself on several occasions.)
Dcyhper.net doesn't need to release their code to coopereate with anyone else. One only needs to know what section of the keyspace (i.e. what keys) each will be processing. CSC may not be as forthcoming as a linear search of the DES keyspace, but there are still keys to be checked.
There were two problems with DeepCrack (read the board minutes where BovineOne explained the options.) First, DCTI processes both the key and the compliment of the key (neato DES optimization) while EFF processes only the key. So, for every DCTI "block" assigned to DeepCrack, it would have to test the keys in that block twice -- the key and the compliment of the key. Second, DeepCrack eats much larger chunks of the keyspace. If DeepCrack were handled as a regular client, it would need it's own key proxy -- DC needs contigous blocks larger than the proxy network could handle.
In the end, the keyspace was broken down into 32 sections. DeepCrack started at one end of the sub-space and the DCTI proxy network from the other end. I'm not certain how the keymaster figured into all this. I wrote a perl script for dbaker to tally the key rate from the proxy network and DeepCrack.
In DES (and this is true for CSC too), we picked some 'interesting' bits from the 56 of the key, and we're using them to increment the key to be checked each time.
This is not to obfuscate the process but for performance reasons.
These bits are definitely *not* contiguous.
For example, we can check key 0x01234567890123 and then 0x45798AF1245EBC and then 0xEFB47870E01901 etc
So the keyspace is *not* contiguous.
If dcypher and d.net haven't choosen the same bits, it's nearly impossible to say "ok, we will check keys from xxx to yyy and you will check keys from zzz to ttt).
For DES, these 'interesting' bits were :
3, 5, 8, 10, 11, 12, 15, 18, 42, 43, 45, 46, 49, 50
Now, you understand ?
--
Rémi
(broken english spoken fluently)
"The odds are 1 in 9,617 that this participant will find the key before anyone else does." Thats with my little K6-2 on distributed.net. Im sure the odds are better with dcypher.net( I hear that they have a faster client). 1 in 9617 is still better then the odds of finding ET with SETI :)
I have to return some videotapes...
For dcypher csc client, a PII500 can pump out 25-30 2^32 blocks, if the contest lasts 100 days, that would be 25*100=2500 blocks, your chance to win is 2500/16 million=1:6400. The $10,500 csc prize might appear silly comparing with those multi-million lotteries, but the odd is thousands of times higher also.
I see where they say that they give you the full prize money (right on their front page), but where do you get that their clients are faster? I searched their site high and low with no luck validating your statement. In the future please give reference points.
Wouldn't that be the decision maker on whether to run dcypher or distributed's clients?
- Dekaner
Care to qualify that remark? Why is it garbage?
The timelimit doesn't matter. Assuming you're crunching keys as fast as possible, you're going to go through roughly the same number at either project. If the prize is five times higher with one project, then go with the one with the most prize money.
But, you know, they really should cooperate. Share the keyspace to avoid duplication, that way at least someone will get the money. They could just say 'We get 0x0000... to 0x7f00... and you get the rest. When one of us runs out, we'll split up the remainer.'
Sort of prisoner's dilema-ish. Help your opponent a little bit, risk being cheated, to reap greater rewards if you both cooperate.
I think here in the UK the chances of winning the lottery are 1 in 14 million something (is this right?) So for DCypher you'd get worse odds, and end up winning a pretty pathetic some of money in comparison. Hardly a gamblers dream win, is it? ;)
http://xempt.darpa.org/dcypher/FAQ/
Unfortunately its timing out right now from here at work... but I believe the information your looking for is contained there.
From personal experience the Dcypher client is ~2x faster than D.net's
Rosie_BHJP
A radio maverick jumps to internet only. The Future of Rock n Roll
I think what is more interesting about all of these projects is not solving the problem posed (ie decryption, SETI etc) but exploring the much more interesting problem of how up use up the vast ammount of underutilised cpu available out there. The bait is of course pride / money to get you to take part. Personally I would like to see more moves towards a system to safely and securely distribute computing jobs across the net A London Coward
ah - but it doesn't cost you anything to enter (assuming the extra cost of electricity used by running CPU at 100% rather than 2% is small)
--
-- Kernel Panic: Error reading
It's unfortunate that dcypher.net chooses to post to slashdot anonymously, making this type of confusion possible.
dcypher.net has never approached distributed.net to discuss cooperating in the CSC contest.
The truth is, that unless dcypher.net releases their code, cooperation is impossible. CSC, like DES, is a bitslicable algorithim. This means that performance improvements can be achieved by overlapping common work for multiple keys.
Since the dcypher.net cores are not available, there is no way for us (distributed.net) to know what real range of keys is represented in one of their blocks.
Even knowing the start block and size of the block, without knowing the details of their core, there's no way to be certain what work is contained in the block.
Even if we did know the full details of their code, if the two codebases take differing approaches to optimization (which is likely), coordination of the keyspace might still prove to be cumbersome and impractical. This is exactly the situation distributed.net faced when we joined forces with EFF's deep crack box during the most-recent DES challenge. Due to the nature of deep crack's bitslicing, we had very little flexibility in subdividing the keyspace. We had very few options for the division that did not involve duplicating work between the distributed.net network and the deep crack boxes.
...or so the guys in the strnage suits told me...
--
Xenu loves you!
This is not a lottery at all. Everybody having checked false keys before increased the chance of the right key being assigned to you, so they _did_ help with your work.
For many of us, we do believe in the existance of aliens. But we can't trust the method SETI using to search ET. Don't want to start a flame war here. The more you read the details about the seti and its associated EM wave transmission theory, the less likely you would believe them would find something by current method. You would never dig diamond in your backyard, wouldn't you? SETI client puts a signiciant impact of system performance for many people while rc5 clients just work smoothly. Plus the facts SETI double,triple issue same blocks to clients, unstable servers, etc. I won't have any desire to put their client back.
I celebrated my first computer by pouring hot grits down my pants !!!
We (DCypher.Net) offered to split keyspace to avoid duplicate key checking, but we were turned down by distributed.net which prefers to walk across keyspace in random patterns instead of doing a linear exhaustive search. So we tried :)
Above all it accomplishes two things: - it is a good test of a distributed computing infrastructure for other projects - it brings in money to attract participants that will follow into more interesting projects afterwards (and if you choose to keep a chunk of the prize you can feel like Bill Gates for making them work their butt off for your wealth).
There's a link right on the front page:
http://24.141.28.12/cscstats/speed.html
So DCypher clients are approximately 2x faster. The figures (which you can of course verify) are actually a bit on the low side, with the MMX core my K6-200 gets around 280 kkeys/s (compared to the 218 kkeys/s listed).
The way I see it, thanks to distributed.net's greater total horsepower the contest will be finished on time, so that's no reason to select them. With DCypher I get more money (and yes, should I win I will donate some to a charity of my own choosing -- right now d.net's top charity is d.net itself!) and, thanks to faster clients, my computing power is maximized.
Cheers,
-j.
You forgot Rise The Rise Mp6 is an MMX monster (doing upto 3 mmx ops a clock)
I'll post this under anonymous coward, but it's Steve Porter (steve@dcypher.net just to clear it up, you can e-mail if you really wanna verify this). I am trying to get my hands on a PowerPC based machine to at least get teh basic infrastructure ported for this and future projects. However, g3s are nearly unavilable in this area, and Apple refuses to return my phone calls, when their Canadian PR center is a 45 minute drive from my house and could LOAN me a machine for a week. You want support for your mac, then maybe you should tell Apple to make it easier on developers. Considering dcypher.net has no revenue at this point in time I can't go and drop $4K on an apple system. Steve
We recommend you go and bench them for yourself. Please note that DCypher.Net blocks are 2^32 keys while distributed.net ones are 2^28. To calculate kkeys/s divide DCypher's kbps by 64.
We put up a short table at this location for some selected CPUs.
ProcessTree - Isn't it time your computers started paying for itsel
Actually we'd love to provide support for the PPC platform (whether it be under Linux or MacOS), but for lack of a dedicated PPC platform programmer it cannot be done. We have one primary coder working on Shadow (DCypher client 1.1) right now, one coder for Linux/FreeBSD porting the code and one database wizard. That's all we have to our name and we must allocate our resources wisely to create the most efficient infrastructure for post-CSC projects, of which we have tagged one so far. If, by any means, you feel competent to port x86 MMX-based assembler code to the PPC platform, feel free to contact our lead programmer at steve@dcypher.net and offer your help :)
ProcessTree - Isn't it time your computers started paying for itsel
Nugget, I thought we discussed this today. I did contact distributed.net (I didn't make the above post) and we (dbaker and myself) could not reach any acceptable way to split the keyspace, so we didn't. I was hoping you would have updated your post by now, but since you haven't I can't let this sit hear HILIGHTED like this when it is SO inaccurate as to what happened. Steve Porter Steve@dcypher.net
Discovering radio waves from a galaxy hundreds of light years away that were inadvertently beamed this way is not going to have that great an effect on our society or world. Yes, it will be a triumphant discovery. But what are they saying? When were they sent? What did those creatures look like? Without answering those questions, the average citizen just won't care.
If on the otherhand the aliens show up on our doorstep, yes, everyone on the world will stop and take notice, and yes, it could have profound effects on our lives. But simply identifying radio frequencies that appear to be non-naturally occuring in a galaxy so far away that we don't stand a chance of us or our kids or our kids kids see what originated it, well, that'll end up being something that really only scientists and "geeks/nerds/fill in the blank" will care about.
And people need to realize that it is not only LinuxPPC. The MacOS/PPC version of distributed.net's RC5 client was last updated in January of this year. There have been no reports of development on AltiVec optimizations. Mac FBA clients have been "in progress" for almost *two years* now. That is simply unacceptable.
I am cracking RC5 keys at 1.25 Mkeys/sec on my dual processor clone.
There is no MacOS CSC client from distributed.net or dcypher.net This is eliminating a large group of people willing to crack keys. Since distributed.net is not breaking up stats by OS/platform, it is difficult to say how many MacOS clients are out there. The EvangaList, at second overall, has over 230,000,000 blocks completed.
I understand that it is difficult to support every platform out there. With the size of distributed.net, at least, it is difficult to imagine that finding a Mac coder is that hard.
If distributed.net does not release a new MacOS client by the end of the year, their client will no longer be running on my computer. I hate SETI, so I will not go to that.
Are there other contests out there that support the MacOS platform?
- (c) 2018 Hank Zimmerman
Hmm.... sounds like the situation with Microsoft to me... Inferior code, lots of users, use simply because it's the most prevalent solution, arrogance in that "we don't need to optimize the core because we have so many users"
Wondering if distributed.net has gotten into talks with Billy G.
Don't get me wrong, I've got the d.net client running right now, and I have been since a year or so ago, but the situation with CSC is pretty funny.
Jonathan Wang
Actually, IIRC the PPC chip is RISC (late 1980s instruction set) whereas x86 is CISC (circa 1970s instruction set). If you'd like to back your claim that the x86 architecture is superior to the PPC architecture please feel free to do so.
Jonathan Wang
Thats what the instruction does - but does it really do it on one clock??? Am sure it saves, but to do 4 additions you would need 4 interger processing units, else treat it as one very wide word + carry/oflow logic. I thought Athlon has dual xPU , so I would imagine Athlon doing better still.
I don't know what my CSC chances are w/ d.net (server's offline right now :), But I get a kick out of looking at my RC5 stats and seeing something like:
"The odds are 1 in a billion trillion that this participant will find the key before anyone else does."
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
dcypher.net is giving the full 10,000 (~$10,000) Euro's unlike distributed.net's $1000. Dcypher.net has a much faster core too.
What's the difference between this and distributed.net? I just installed the rc5des client today and noticed that it also did CSC--so what's the deal? how do these differ?
Jeremy
Looking for a Python IRC bot?
I got my first computer when P-II was out so I was never explained what MMX really does for you.. Can anyone explain?
Movie News - "Entertainment news, bitch!"
Does the Celeron processor contain the MMX instructions?
I am the Anonymous Coward!
Working on that. DCypher.Net
Distributed.net and dcypher both try to solve the CSC contest.
The distributed.net network is currently crunching keys 8 times faster than dcypher.
At the time of this writing, d.net is the only network which seems to be able to solve this contest in time (remember that CSC is time-limited, any solution found after March 17, 2000 is void)
D.net source code is available to anyone who wants to improve or just review it : http://www.distributed.net/source/
Right now, d.net have clients for
- Linux x86
- Linux Alpha
- Linux Sparc
- FreeBSD x86
- NetBSD Alpha
- DOS
- Netware
- Win16
- Win32 x86
- Win32 Alpha
- HPUX 10.20 (HP-PA 1.1)
- IRIX 5
- Solaris Sparc
Once again, those of us running Linux on PowerPC hardware get to be second-class citizens.
Now, I realize that the majority of boxen out there are x86-powered. So, sure, one would expect to see clients for distributed-cracking efforts to be x86-first (and Windows-first, unfortunately). But, c'mon. Once a Linux-x86 binary is posted, there's just no reason not to spend the couple of hours or so it would take to find someone who would be willing to compile and test the same code on a LinuxPPC box.
PowerPCs are make great crunchers. With distributed.net's RC5-64 client, my LinuxPPC box at home (with a 270MHz PPC750) hums along at around 920Kkeys/sec -- about the same speed as my previous box at work (a 333MHz Pentium II). All of this despite the fact that the d.net client for LinuxPPC hasn't been revised in almost a year and has some pretty glaring bugs (most notably hostname lookup failures -- and this could probably be fixed just by re-linking the dang thing). Both the Linux-x86 and Linux-Alpha clients are at version 2.8x and have received some attention lately, but the LinuxPPC client is still at 2.7x has apparently been left behind.
Myself and other LinuxPPC friends of mine have tried to volunteer our time and boxen for various projects to compile and test LinuxPPC clients. We rarely get any response.
I'm becoming disconcerted with the growing trend/mindset that: (Linux == Intel). This was always one of Windows' biggest drawbacks, that it was tied exclusively to one architecture. Through sheer laziness, I fear the same fate for Linux. It doesn't have to be this way.
And, yeah yeah, I know x86 hardware gives you more "bang for the buck." Yawn. Thankfully, not everyone in the world wants to drive a Camaro. How boring would that be?
I really don't see the reasoning behind cracking these encryption routines. Surely we know that by throwing enough computing power at it, we'll get there eventually. So why bother with it? What does it actually achieve? This isn't flamebait. I'm generally interested in why people want to do something like this.
I'm a fan of SETI, since it's an attempt to discover something new. If you believe in the possibility of extra-terrestrial life or not, surely from a scientific standpoint, SETI is a far more worthwile use of computing power, isn't it?
notext
I believe you will see alot more of this in the future. With the Internet, we can connect hundreds, if not thousands, of computers to perform a single task. Well, actually, each computer will perform a segment of a single task. With more and more computers hooked to the Net doing nothing, we could use these machines for advancing technology. I would prefer to have the source to these programs that get installed, or atleast an outside inspection of the code, since you could abuse this access into other's machines.
This contributed effort I think is a Good Thing. But like I said, it should always carry the source with it. I know that this could cause problems with those that tweak the code and create problems with the final project. There should be a way to check against this. Like randomly giving the same tasks to different computers, and comparing the result of both.
Who knows, maybe someday this will help in curing diseases and diagnose DNA.
Steven Rostedt
Steven Rostedt
-- Nevermind
where is the source ?
;-)
---
When i first joined the seti@home project in february, i believed their promises to release the source later...
now i no longer run any seti@home crap on my systems, and kill every user-run process i find.
-> No source = no trust.
i dont give a damn about some remote chance to win some bucks - be it 10000€ or 2000$ - when i can't verify the integrity of the code i am suppost to run on my systems - especially if it exchanges some cryptic data with a remote site.
You might call me paranoid - but my aversion against the idea to run some code which i cant verify is one of the things that pull me towards Unix.
btw: i wouldn't participate at this for the prize money - i would do it to make a point.
(i get more money doing something that is fun for me - and is called 'work' by others
--
Jor
Is this really so unreasonable, though? Distributed.net is a public organization offering membership to anyone and everyone. As such, it has a certain amount of credibility, as none of these people have had confetti made of their PCs. On the other hand, by virtue of being public with unrestricted membership, d.net is quite at risk for unsavory people doing unsavory things. Mistrust is a necessary evil. In short, -you- don't have to accept distributed.net, but -they- have to accept -you-. As such, different trust levels are appropriate.
Don't forget: If we lived in a perfect enough world that this sort of security was unneeded, the projects which distributed.net is currently working on wouldn't even exist.
--neil
I don't want to start nitpicking, but I can't help pointing out the fact that althought there is code for something like the d.net client, it is not the source code for the client. I personally don't mind much this (it's their code, they get to pick the license), but I don't like their reasons for not releasing the source for the client. Basically I read them as "ok, you have to trust us not to make conffetti out of your pc, but we choose not to trust you not to make conffetti out of our project..."
Typical : "My PoverPC G8+ can do 9721.57 Key/s ! Hey your pentium sucks so much" ...
Or "My Quad-Xeon linux server puts the smack on your Athlon-500 on RC5 ..."
If there were NOT stats available, these contests would never work.
Discovering radio waves from a galaxy hundreds of light years away that were inadvertently beamed this way is not going to have that great an effect on our society or world. Yes, it will be a triumphant discovery. But what are they saying? When were they sent? What did those creatures look like? Without answering those questions, the average citizen just won't care.
Are you crazy? It will drastically influence society. For one it would debunk a lot of religious beliefs, as it will (hopefully) foster a new interest in the sciences.
This is getting way offtopic, who moderated this clown up?