Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
The Internet

Distributed.net Does CSC 105

Posted by Hemos from the joining-the-fray dept.
The fine folks over at Distributed.net have appraised me of the fact that the long awaited CSC clients have been rolled out, as of a few hours ago. The full details went out on the mailing list recently regarding CSC and the new clients. Upgrade your clients, because they'll start serving keys in just a couple hours, and we can keep Team Slashdot in first place.
This discussion has been archived. No new comments can be posted.

Distributed.net Does CSC More

Distributed.net Does CSC

Comments Filter:
  • Are there any other projects like distributed.net out there? (P.S. FP!!)

  • Other Distributed computing projects (Score:3)

    by Latrell Sprewell ( 6906 ) on Tuesday November 16, 1999 @06:00PM (#1526553)
    Check out George Woltman's links to distributed computing projects [mersenne.org]. This is not a comprehensive list, but includes most of the famous math/science related projects out there.
  • Is there any estimate on how long this is going to take? DES-III took some 72hrs I think and that was a 56bit encryption... Are there any pages with more information on the CS-Crypt algorithm?

    All the more reason to get off yer lazy butts and update your client! the contest gets online tomorrow! I've updated mine... and added my little Indy to the mix :-) (yay it gets some 78kk/s on RC5 ... RS4000 processor yay!)



  • lightbulb (Score:4)

    by Signal 11 ( 7608 ) on Tuesday November 16, 1999 @06:07PM (#1526555)

    *groan* distributed.net has been running closed clients for awhile now. What I wouldn't give to know what makes those things tick. Well, time for a shameless plug... a friend of mine (and myself!) are working on a program that has some rather, ummm, interesting features. Namely it's distributed processing (hence the post under this thread!). What makes it cool is that a) we're releasing it under GPL, and b) has never been done before.

    You see, my friend has thrown some genetic programming together with some math syntax checking / validation and created a novel program that can reverse-engineer algorithms. You give it the inputs you fed the "black box" and the output(s) it produced, and it divines what algorithm was used to do it. You can immediately see the benefits here. So I thought I'd plug it - it's a helluva lot more flexible than distributed.net (anybody can run a server - you got the source!), it's free, and it may be one of the first so-called 'software patents' to be licensed under GPL (as soon as I have some spare $$$, I might just do that too!). Oh yes... did I mention we're cooking some algorithms right now that'll hopefully let you find primes on a linear timescale instead of exponential? *evil grin* Noooo Mr. NSA... that's not *my* algorithm.... =)

    If anybody's interested in pitching in, we could use a few extra hands getting the code all nice and prrrty and out into the hands of fellow slashdotters. =) mail me [mailto]!



    --
  • Linux clients should be about tonight as well. Lets not forget the winning keycrackers takes the entire prize!

  • We're rolling... (Score:5)

    by dbaker ( 7409 ) <dbaker-slashdot@cuckoo.com> on Tuesday November 16, 1999 @06:08PM (#1526557) Homepage
    We've already started serving keys and our users' clients are happily crunching. Anyone firing up a new CSC client should expect to receive CSC blocks immediately.

    As of the time of this post (04:00UTC), we're just about to hit 200Mkey/second. We've completed a little over .007% of the keyspace. Although this seems very slow, it's an amazing start for a project with clients that we just released. At this point, we've distributed thousands of clients, but most won't report back until they've completed ten blocks. I expect the rate to have a huge increase in the next few hours as clients start submitting their first blocks.

    Daniel


    --
    Daniel Baker - dbaker@cuckoo.com - dbaker@distributed.net

  • Very little of the client is "closed". In fact, we just released a new distributed.net source tarball [distributed.net] today.

    Feel free to hop on over and check it out.

    Daniel
    --
    Daniel Baker - dbaker@cuckoo.com - dbaker@distributed.net

  • Is it just me, or do none of the distributed computing projects seem to be OSS? I have a rather odd system in he corner (NeXTstation Color running NeXTstep 3.3) which I'd love to use for distributed computing. However, none of the projects I've seen have a NeXTstep client, and none of them are OSS, so I can't port it myself.
    Information and/or suggestions will be appreciated.
  • Hmmm,
    Prime factoring on a linear timescale. Doubtful. I'm pretty certain any number of people have tried your method, and since just about every encryption protocol based upon this method is still standing, I would assume noone has done it. And if they did, I'm sure the NSA would quickly have their hands all over and would quit trying to prevent encryption from spreading.
  • Okay... I inserted my foot firmly into my mouth there. But still, I'm looking forward to doing this via the GPL - I think it'll be a blast.. even if the whole thing fails miserably due to some of the problems you outlined on the link you provided. =) May my code compile cleanly, my fingers move deftly, and the whole thing segfault quickly.

    --
  • According to the announcement page, there is a 10,000 euro reward for cracking the CSC challange. Would that mean if we win we get the euros? Or do they convert it to US dollars for us?

    --
    http://savethelaptop.zzweb.com/: Tips and programs for protecting your laptop
  • you are basically correct, the contest projects are not OSS, becuase of the problems of "hacked" clients. As far as we ( distributed.net) know no one has solved the problem of having a OSS client and proving the data returned is 1. correct , 2. done by the exact OSS code, and 3 the results are not used bypassing the group effort.

    there has been a bunch of discussion in sci.crypt for the last week from the seti@home group about the same problem

    dave
  • If we have a full userbase switch, we expect a 100% exhaustion in ~1 to 2 months.

    That said, of course, we wont be able to get a full userbase switch, but chances are that we wont have to search 100% keyspace either.

    In a few days we will have a better estimate of course, because then we will know real keyrates.

    Ivo

  • CSC Rate Clock (Score:3)

    by Evan Vetere ( 9154 ) on Tuesday November 16, 1999 @06:22PM (#1526565)

    I've put a rate clock up for this contest. It refreshes every two minutes and is continually updated by the master keyserver. Stats don't get any more accurate than this...

  • =) Something I once read about engineering - "too much reality can doom an otherwise worthwhile design". Maybe it'll work, maybe not. I can tell you the program can map out simple algebra pretty quick (about a minute or so).. and even if it can't factor primes, it'll likely raise cain on alot of other things! We've fed it a list of primes and let it run overnight. It's been making small improvements. It started at a fitness of 8 and slid down to a 4.7 over a 24 hour period. I wish we had some time on a supercomputer to run this - we could find out right away whether it would work or not. :(

    No matter what, it'll be a crazy ride, and useful to somebody out there!



    --
  • See also here [distributed.net] for most of the source which IS open.

    If you can port these sources/cores to your platform, we'll be happy to make a client wrapper around it!

    Oh, on that page is also an explanation why we still are not open source...
  • distributed.net does have a NeXTstep client, it's listed under NeXT/OS on the client page.
  • Woohoo. Uhm, pretty soon there will be an article in here about how the check is being handed over to me, cause i'm gonna crack it and win those euros... probably not, but you can dream, right? Anyway, join team #10690 or the donkeys will come get you.
  • Www.dcypher.net is offering the full 10k to the winner. WE also have clients that are ~2x faster.

    Unfortunatly linux clients wont be out till later tonight.


    www.dcypher.net
    Chris Harrison
  • Almost every game available has been cracked, it's not that hard to reverse engineer software obviously.

  • Client core source - the source that does the actual crunching - is entirely open and available at our web site. [distributed.net]

    We have good reasons for not releasing our network's source. One is that we would become instantly vulnerable to block spoofing, threatening the integrity of the effort.

  • d.net *could* be so good (Score:3)

    by Jeffrey Baker ( 6191 ) on Tuesday November 16, 1999 @07:01PM (#1526581)
    I have been running d.net clients since the first months, using my trusty P60. Today I have the clients running on some serious hardware, and I still plan to run them in the future.

    I am somewhat disappointed that the folks running d.net continue to make the same mistakes repeatedly. First, and in my eyes worst, is the fact that they are not able to advertise their contests worth a damn. Take a look at their home page. The announcement of the CSC contest starting is after several paragraphs of numbing boredom, in the same typeface as everything else. Distributed.net needs to learn to use the H1 tag. If they want people to switch their clients, they need a big, flashing siren or something!

    The second problem is one that I'm sure a slashdotter with more time than I have will cover more thoroughly here. In short, the clients need to be opened. If you must obfuscate the block authentication scheme, then you have no authentication scheme to speak of. The poor design of d.net client security has been demonstrated by multiple occassions of people faking results. One principle of security is that you should always assume that the attacker knows exactly how your security mechanism works. It would be great if d.net could overcome this problem and harness communal brainpower for testing, bugfixing, and enhancement. Think of open source as a distributed.net for brains :)

    -jwb

  • It says on their page that the CS-Cipher supports 0 bit keys! Woo hoo, no bothersome password to remember! Someone should patent that!

    ...what do you mean plaintext is prior art?
    ---
    pb Reply rather than vaguely moderate me.
  • I'm currently running rc5des. I just installed the new CSC client. Does this totally REPLACE rc5des? Or am I abandoning the rc5 project for a new CSC project?

    Thanx for enlightening me.

  • I'm only going to comment on the first point, as you've brought up precisely what I am now responsible for [distributed.net] at distributed.net.

    You're absolutely right. And we're working to fix it.

    We've finalized a redesign of our web site and are beginning a complete rewrite of nearly all of our web content. After the major pages are finished, we'll go to work on the documentation, which is very lacking, often in some extremely important areas. The site will have a new hierarchial structure, with simple URLs for news, help, and downloads. Deep information will be even more readily accessible for those diehards who want it.

    The changes will be rolling out in stages over the next thirty days.

    Come back to distributed.net in a month's time. I promise, you won't be disappointed.

  • The dnetc client does replace rc5des as a program, but it does not replace what it can do, it just adds the CSC Project as a project option.

    If you want to work on RC5 and not CSC you need to set your Project Order to something like the following

    RC5,OGR,DES,CSC

    If you want to go ahead and work on CSC something like the following will work great

    CSC,OGR,DES,RC5

    This tells the client to work on CSC then OGR then DES then RC5, in that order. You can always go back to working on RC5

    I hope this helps.

    Moose

  • No, actually you can stop chewing on that foot. Much of the client is still closed-source. Here are the reasons they give (on the same page linked from above):

    Why is distributed.net still closed-source?

    Although we are providing all of the code linked on this page for public perusal, it is still necessary to keep select portions of the codebase unavailable for general distribution. Indeed, this is an aspect of our operations that we would very much like to be able to eliminate. However, there are several motivating arguments against open-source development with the current clients:

    • there exist people who would want to modify the client to purposely report unchecked blocks as being completed for the purposes of raising their statistics.
    • others may want to ruin the project for everyone by intentionally opening the possibility of bypassing the solution key.
    • the project could additionally be spoiled by attempting to overwhelm the keyservers by falsely submitting fake solutions or fake completions.
    • although unlikely, it is possible that home-made binaries contain coding mistakes or compilation errors. Admittedly, binary-only clients released by distributed.net could also contain errors, but the chances of such an error remaining hidden for long are virtually zero, and once such an error is discovered by us, we can confidently exclude blocks reported by specific binary versions of the client that are known to be defective.

    Thankfully, they realize that client-side security is no security at all, and appear to be working on a server-side authentication method.

    I admit, it would be very nice to have the complete code-- especially for people experimenting on bizarre high-end hardware. At one time I was very interested in building an HP-PA 2.0 version of the client, but alas the source was not to be had. I also had some PowerPC 620 system running AIX which could have been used-- note the distinct lack of any AIX clients this time.

    Here's to hoping that either:

    • People stop vandalizing useful projects, rendering the need for security obsolete. (Hey, I can dream!)

      or...

    • They get some good, solid server-side security set up soon.
  • I'm currently running rc5des and have for months.

    Should I switch to dnetc?

    Which contest gives me the best chance of winning?

    In other words, for which client is (Keyrate)/(Total Keyspace) Higher?

  • Why isn't mine moving very fast then? I've been running the thing for almost 15 minutes, and have only 5 periods. On RC5, I'd have 8 or 9 now. I figured that CSC would move faster. Are the blocks bigger?

    Wow.. in the minute it took me to write this, it went up to 310.38. Moving right along.
  • And if anyone noticed, they haven't had the regular single CPU version up for MONTHS! I now have to use the MP capable one. If I am out of the room on startup, the warning message that it may not run correctly on my system stays until I return. I guess I should just find a copy of an older client. But I don't get why they seemed to have abandoned the Mac clients. Maybe because they were jealous of team Evangelista?
  • Aargh, this is annoying. I mean, I heard rumours that the beta client was a little slowish, but I just benchmarked the d.net CSC client on my machine, and I got about 380.4kkeys/sec cracking rate (it's a K6-2-300).

    It there a problem with some systems, software-wise, or is there a bug in the d.net implementation of CSC? I tried out the DCypher.net CSC client (it's been out for a week or so, I think) and for 732.6kkeys/sec on the same system, under the same circumstances!

    Actually, I checked and I'm finding similar comparisons from various people I know, with d.net's CSC client being about half as fast in cracking compared to DCypher.net's (a friend of mine tried both on an Athlon-650 and got 2,023,437keys/sec for DCypher and 1,040,189.47keys/sec for d.net, for example).

    My testing is being done with all programs except the shell and systray (and a dos box, as I'm using the command line clients) closed and out of memory.

    Is this an optimization issue? Will d.net release improved clients in a few days? I'm really getting worried and annoyed. I had planned to do a DCypher-CSC/d.net-CSC comparison on my website to show which was faster on which of a variety of cpu cores. But this is insane!

    Oh ... ummm, I guess it's only fair that I link to DCypher [dcypher.net], as they're kinda the underdog here and not as many people know about them.

    -JC
    PC News'n'Links
    http://www.jc-news.com/pc [jc-news.com]
  • If you must obfuscate the block authentication scheme, then you have no authentication scheme to speak of.

    But authentication, in the sense of "who submitted this" isn't the problem. The problem is trusting the results. Quite a different problem.

    -- Abigail

  • One of my favorite definitions, especially the storage aspect:

    2. Base one. A number base with only one digit, namely zero, and which can therefore only be used to express the number zero. Attempting to add one to zero results in an infinite sequence of carries. Numbers in unary notation can be represented particularly efficiently however since each digit requires no storage.

    (1998-07-29)


    Source: The Free On-line Dictionary of Computing, © 1993-1999 Denis Howe

  • I suppose this is a joke, but it doesn't make much sense to me. For example,

    0 = 0
    00 = 1
    000 = 2
    0000 = 3
    ...

    or,
    0 = 0
    00 = -1
    000 = 1
    0000 = -2
    00000 = 2
    ...

    so you can represent any natural number with a modicum of effort..it is however, not very efficient :-)

  • THE COW! (Score:2)

    by Anonymous Coward
    The biggest selling point for most of my friends who allow me to install the rc5des client (now known as dnetc) on their machines has in the past been the funky little cow. WHERE'S MY COW!!!! I WANT MY COW!!!!! How am I supposed to tell people about the cute cow that cracks crypto if the COW ISN'T THERE??? sure - we got a funky little blue thing, but its not cute, not cuddly, and my girlfriend will hate it! Come on D.net, GIVE US THE COW!
  • On the plus side, run length encoding kicks ass in base zero!

    On the minus side, null-terminated strings suck. And terminating everything else is pretty bad too. So find an OS that supports files, and store your numbers in separate files. I'm sure a work-around will be out shortly, but don't switch from your Turing machines just yet...
    ---
    pb Reply rather than vaguely moderate me.
  • Maybe I'm the only person who thinks so, but to me, brute force compromise of 56 bit keys proves absolutely nothing at this point. Everyone knows that a 56bit keyspace can be searched in a relatively short period of time -- big shit -- so what?

    Its a challenge. distributed.net makes use of spare cpu cycles. I'm currently using 30+ machines cracking rc5-64. I'm not sure if I should download the new client, but I'm considering it. There is no reason whatsoever to have so much machine power go unused.

    Otherwise distributed.net stands as the biggest coordinated waste of CPU time.

    No. You waste cpu time if you do NOT run some sort of client. My rc5des clients run at nicelevel 20 (the default). That makes it use .. well, almost no cpu-time whatsoever -- that other programs would've used.

    At least SETI has some productive goal.

    Uhm.. I don't think so. Crypto is something that is important to us HERE and NOW. IF we discover ET's on some distant world. Say a star 100ly from here (that's not likely, far too short a distance). If we find that there is a POSSIBILITY for life there, and send a signal back -- they'll receive it in 100 years. If we wait 5 years sending the signal -- it will have no effect whatsoever.

    Crypto on the other hand, is important to us in daily life. It is needed that governments remove all restrictions against crypto.


    --
  • The poor design of d.net client security has been demonstrated by multiple occassions of people faking results.

    I'm curious. Exactly how should this security be implemented? I'm no security expert, but I've read a bit now and then.

    Nobody should need to 'register' to be able to participate. It should be as easy as downloading the client, then download blocks, then crack them. If its to much work to set up, only die hard nerds like you and me would want to.

    Of course, there is no problem making sure of who the packets coming from. Do it with some sort of private/public key system -- where the sender sign his keys. I don't understand WHY we should do this though -- as anyone would love having keys sent in as him.

    So, how should one make sure a key is really scanned?


    --
  • Here I sit, working late on Mac OS X, with a G4/400, a handful of G3s, and a 9500/180mp (dual 604e), and no client to run.

    I've lost track of the number of nights I've pondered porting the RC5 client to Mac OS X, or AltiVec (er, "velocity engine"). But there is no source for the RC5 clients, so my machines get rebooted to Mac OS 8.6 every night when I go home to crunch RC5 at about 1300kk/s ea.

    Sorta sad.

    (BTW- don't tell me to email them to get on the porting team. I want to putz with it when I have 5 minutes. I don't want to have to join a group.)

  • Interesting... I extracted the new client (under Windows 98), and it took over a minute to extract, with 100% CPU usage, jerky mouse, and no HDD activity. I finally figured out that it was the F-PROT (F-STOPW) that was the culprit. It reported no error, didn't detect anything, and didn't even report it as suspicious, just took over a minute to check it. Weird.

    So anyone running a virus checker, don't be surprised if copying/extracting the file takes forever, and you may want to set your virus checker to ignore it once you have checked it in the first place. Especially if you use F-STOPW.
  • I just installed the client (Win32 version) and gave it an hour or so running with virtually nothing else running on my system. I'm getting about 660,000 keys per second on my PIII 450 @ 600MHz. This is with the default client options, mainly processor priority at "0" (at idle). What kind of speed are your systems cracking at? What system configurations? I think it's interesting comparing rates...
  • Ok, first note that I am so far from being a lawyer that it's rather humorous. Oh, and also note that I didn't think of this idea myself; it came from this rather fascinating article [salon.com] in Salon a couple months back. (Yes, it made /. at the time, but only as an update to an article about a new Beowulf for running GP.) And, yes, this is very offtopic.

    But basically, the idea is this:

    1. A prerequisite for an idea to be patented is that it's not obvious, even to the best experts in the field. That is, there needs to be some flash of creativity involved--some something that no one else can be expected to think of. This is why patents are supposed to be in the public's best interest--better to have the ability to use the idea in a "limited" amount of time (currently 95 years and counting) than to potentially never have anyone else think of it again. In the case of a patent on an algorithm (which covers just about any software patent), it's not enough that the problem the patent solves be novel--indeed, it should be relatively obvious; what needs to contain that unique insight is the algorithm itself. (Yes, this is how it's supposed to work, even though just about all the absurd patents /. links to seem to be precisely the opposite.)

    2. A good genetic programming environment--like this one, if it becomes successful--will theoretically be able to come up with an algorithm that implements any "solution" one would feed into it. A great one would even find an *optimized* solution. (Indeed, in the Salon article, it talks about genetic programs which have produced algorithms or schematics identical to 21 existing patents, and one which even lead to the discovery of a new rule in quantum theory!)

    3. A computer program, even one that implements genetic programming, is a mechanical process. It is entirely deterministic, and can be simulated by anyone, assuming they have the CPU resources (especially if the program's open source!). Thus, anything this program thinks up cannot possibly be "nonobvious"; a nonintelligent computer just came up with it.

    4. Thus, any algorithm this program can duplicate is nonpatentable. It may even be that any old patent this program can duplicate without specific knowledge should be retroactively unpatented, since if it's "obvious" now, it had to have been obvious then; that is, if the machine is not true AI (which of course this isn't), then it's not intelligent always; it's not like it can be "intelligent by 1950's standards but not by today's".

    So...an interesting strategy to fight evil software patents. And indeed, perhaps to fight all patents, although of course it's much less obvious how to get a computer to create a non-software process.

    Of course, it'll prolly be a ways off before a genetically created algorithm nullifies a patent. Still, I wouldn't be surprised if some time surprisingly soon, the entire idea of patents is very substantially curtailed, if not eliminated, due to this sort of thing...


  • It sure cuts down on the number of dorks faking keys though. Security through obscurity should never be relied on, but it works as a last line of defense. (ie, very slightly better than nothing).
  • By this time, we can't crunch...
  • This isn't cast in stone, but we would most likely convert it to US$, since there would most likely be a 10kEuro check made out to us, and then we would split the prize 60/20/10/10 to the charity voted for by the participants [distributed.net]/distributed.net itself/the user who finds the key/that users team (if the user is not on a team, they get 20%).

    If the winning user or team were located in Europe, we might ask CS if they'd be willing to send checks directly to them.

    Decibel
    distributed.net Controller
    decibel@distributed.net
  • IANAC (I am not a coder :) ), but we havn't done any core optimizations in the current client. If we get a large portion of our users converting over, we probably won't have to either, since we could exhaust the entire keyspace in a matter of weeks. Assuming that's the case, we're much better off getting unoptimized clients out the door, rather than spending weeks working on hand tuned assembly language cores.

    One of the interesting things that happens when you get a very large group of CPUs together is that you don't always need or want to be very effecient on the CPU level... it's more important to be effecient at the *network* level. In this case, we're trading off effeciency in CPU cycles for time. Another potential example is algorithms that do not parallelize well, ones that need lots of inter-process communication for example. It might be possible to modify these algorithms to remove some of the inter-process communications at the cost of increasing CPU power needed. This wouldn't make sense if you were running on a single power machine, but if you're using a wide-area distributed computing network, it could make a *lot* of sense.

    Decibel
    decibel@distributed.net
  • sorry, I'm 76 on the Slashdot seti team and I'm not giving up any cycles ;)

  • Any word on when a MacOS/PPC client will be available? The client list seems a lot shorter than distributed's list for rc5/des, but this seems like one particular glaring omission.

  • Insert your foot into your mouth. Witness this [malign.net]. Search freshmeat for mp3db for more info. =)

    --
  • Look harder and accept that the project will be more obscure. The various related number theory projects are open source. Look at the ECMNET [loria.fr] or Mersene page [mersene.org]for ideas. Finding another factor to a Cunningham Number may take 6-12 CPU months, but it does happen.

    You will not find servers or fame, in part because these attract script kiddies and vandals. But it does use those wasted CPU cycles.

  • > I've lost track of the number of nights I've pondered porting the RC5 client to Mac OS X, or AltiVec

    -sigh-

    http://www.distributed.net/source/ [distributed.net]

    Download it, and "putz" with it when you have 5 minutes.

    The strange thing is, this is my second post on this and Daa and dbaker have also pointed this out. Some wanker even pasted parts of that page here.

    How long do we have to hear "I would port it, but those d.net people wont release the cores!"

    The only thing we don't release is the buffer and networkprotocol, for reasons stated in this post [slashdot.org].
  • With everything else sucked out of memory save for the shell and systray, I'm doing a tad above 732,000 keys per second on my K6-2-300 @ 300MHz (using DCypher cli Win32 client).

    -JC
  • 3. A computer program, even one that implements genetic programming, is a mechanical process. It is entirely deterministic, and can be simulated by anyone, assuming they have the CPU resources (especially if the program's open source!). Thus, anything this program thinks up cannot possibly be "nonobvious"; a nonintelligent computer just came up with it.

    This doesn't really hold up under the "common sense" approach of going around to a number of experts in the field & asking "Does this seem non-obvious to you?", although you could probably make a good legal case for it.

  • Somebody has been working on porting the rc5 client to the G4...supposdly they're getting 3.6Megakeys/sec. One of these days we'll see a new client, and then the x86 peeps will understand what real speed is. BTW, has anybody seen the page I'm talking about? A url would add to my credibility.
  • I'm the friend Signal 11 mentioned who wrote Lightbulb. Right now, it doesn't factor primes. I have no plan to make it do so.

    Its purpose is to take a list of the inputs and outputs of any unknown function, and find that function given those inputs and outputs. I figured it would be interesting to find the equation that maps these numbers: (1,2),(2,3),(3,5),(4,7)... Once an equation like this had been found, anybody could find the xth prime instantly by running x through the equation. Not only would the results of such a function be useful, but the function itself might give a mathematicians deeper insights into math.

    Another mapping of numbers that I thought could hold some promise is (1,3)(2,1),(3,4),(4,1),(5,5),(6,9) -- the digits of pi.

    Aside from these great mystery patterns, lightbulb could be of use for everyday data analysis by physicists.

    I'd like to mention that the core of this software has already been written, and it works. The devil is in the distributed-computing details, however.

    We'll keep you all posted on the status of the project, and if anyone wants to help, email me at 3nelsons@pressenter.com
  • Today is my first day at using any distributed cracking client. I found out about it here on /. today, and think that it's a realy cool idea. That said: Dcyper may be 2x faster, but isn't it more likely that the distributed.net effort will be more successful (without optimizing the client to equivalent speeds even)? My reasoning: 1) More people are aware of d.net 2) Being a new "member", I'm more inclined to go with the team/effort that has proven that they can do it (3 previous victories). So without any of the problems of the past (of which i am not aware) taken into consideration, wouldn't the new user (or even the seasoned veteran) tend to trust d.net over the other guy? Just curious.
  • Well, unfortunately I'd have to admit that we don't always move as fast as I'd like to see, but I certainly don't think that we're slow, blumbering, or don't get anything done. In 6 months we've expanded our network to be able to handle non cryptographic contests (OGR), have launched one new contest, and are very close to launching a second new contest. This is on top of all the normal day-to-day operational work that goes on.

    I can understand wanting to have the fastest, most efficient cores possible, we'd also like to see that. But how long do we wait for highly optimized cores (FWIW, I was told by our coders that they did in fact spend time optimizing the cores)? We may only be working on this contest for a matter of weeks, so does it make sense for our coders to spend time on optimizing CSC, when they could be working on finishing OGR? Maybe it does, maybe it doesn't. As it turns out, we've had numerous offers from people to work on x86 ASM cores since the source was released yesterday, so it is quite possible we'll have optimized cores available some time soon, at least for the x86 architecture.

    As far as stats go, I guess that is one advantage that a smaller effort will always have over a larger one: the ability to reach very high levels in the stats. Unfortunately, that's completely counter to the entire concept of distributed computing, where each CPU does a very small piece of work. On the other hand, a new contest like CSC does provide the perfect opportunity to climb in our stats.

    Moo!
    dB!
  • I was running rc5des and switched to dnetc. I changed the progect order to RC5 CSC. The new client is much more efficient: I gained 400,000 keys/sec. Used to get 1,400,000 keys/sec.

  • Finding a faker isn't really that hard. Generally they'll fake blocks because they think it makes them look cool to be right at the top of the stats.

    It's possible to design the client software to submit a false positive roughly every 4 billion keys tested (maybe just test to see if the first 32 bits are correct). It shouldn't be too hard for their servers to keep up with testing one out of 4 billion keys. When submitting any positive, the client should point to the exact key, so that a trusted machine can examine each key more carefully. When testing the key, this machine should test 2 things, is it the winning key, and is it one that should have been returned by the clients as positive. If it is a legitimate false positive, simply log it as such. If the client shouldn't have kicked it out as a false positive, then it's likely a cheater. This is to prevent people from submitting random blocks as positive to defeat the next mechanism.

    Periodically, the proportion of false positives to keys tested should be be checked on. If the proportions are out of wack use a little stats to see how likely they would be out by that much had they been legit (This isn't a difficult calculation). If it looks highly unlikely that this could happen legitimately, again, the person is probably a cheater.

    That's fine if the person is honest about who they are. You have to be honest about your identity for a high position in stats, but if you were just trying to sabotage the effort, you could use someone else's E-mail address. To defeat those people, some sort of authentication needs to take place. For example, when you sign up as a new participant the server E-mails you a password which must be entered into the client. They could even let the participant select their own password by supplying it with the first returned work unit.
  • Here's the URL for the Altivec/Rc5 project,


    http://home.earthlink.net/~alien57/macclient.htm l
  • Its purpose is to take a list of the inputs and outputs of any unknown function, and find that function given those inputs and outputs.

    aka interpolation

    I figured it would be interesting to find the equation that maps these numbers: (1,2),(2,3),(3,5),(4,7)... Once an equation like this had been found, anybody could find the xth prime instantly by running x through the equation.

    hmm. well, the straightforward way to do this would be to start with the first 50 or so points (1,2),(2,3),(3,5)... and interpolate a function from them. then test the function starting at the 51st point until a result is given that is not prime. then interpolate a new function based on all the points up to but not including the one that produced the non-prime result. repeat until no non-prime results are returned. of course, ive not seen your program so i cant say this is how it works.

    the frequency of non-prime results should eventually dwindle down close to 0 as the functions generated become more accurate. aside from the fact that verifying "primality" can take a while for big numbers, the other issue is that theres really no way to tell whether there we'll be no non-prime results for a given equation.

    although, even a semi-acurate equation for pi, e, primes, etc would still be interesting (to me anyway).


    --Siva

    Keyboard not found.
  • DCTI has been jawing about a better authentication scheme (read: getting one) for years. It was being discussed when I "joined" DCTI some year(s) ago. Maybe they'll "invent" public key crypto in a few years. *grin* I don't know what they may be scheming over in the inner circle since I've not been part of that circle for some time now.

    As for odd client builds, one of the coders needs the hardware/OS to get a client built. They usually will not "login and build a client" on the fly -- it's way to easy for the host to snag the source that way. When I had access to the full sources, I'd build a client on everything I could get it copied onto -- to date, I think I'm still the only one with a multithreaded SCO client :-) As long as the OSes that the majority of people are using have clients, then what's the push to support 10 machines? (and then the client for that obscure OS doesn't get updated for a year...)

    Having seen the source code, you're not really missing anything. The code that actually does the work is publically available. As for the buffer and network code, who cares; that stuff is pretty easy to whip together. The only magic is the "crypto" used for the block storage. (it's about as much crypto as CSS is and far simpler. I'm really surprised someone has reverse engineered it yet. I shudder to think what will happen when someone does and publishes it.)

  • The only magic is the "crypto" used for the block storage.

    As the one who wrote that particular piece of code... I can say it's not worthy of being called crypto. It was never ment to be.

  • See also: Cosm [mithral.com]

    The Cosm source code is available via anonymous CVS [mithral.com] -- every single line of it [mithral.com]. I'd have NextStep 3.3 buildable if I had hardware old enough to run it :-) (All my x86 hardware is too new to be supported. And my friend's NeXT's hard drive burned up.) It's installed on a Sparc5 (w/16M or RAM mind you) in the office next to mine but I'm out of network connections :-(.

    You're welcome to assist with code development [mithral.com], porting, or just watching [mithral.com] us go...
  • Simple public key cryptography and "blessed" clients. This method has worked for over a decade with other software.
  • DeepCrack can process DES information in a few days, but they [eff.org] spent months designing it to be fast. It takes a matter of seconds to transfer a block and then hours to process them. The hour long process is the one I'd work on optimizing.

    Yes, DCTI is "slow", but no one is getting paid to do anything, so unless you've donated [distributed.net] something [distributed.net], I'd say everyone is getting what they paid for *grin*

    OGR? I'm the one who did the very first work on OGR -- taking garsp32(?) and breaking it down into something that could be stoped and restarted. OGR doesn't have any discrete "blocks", so it's taken a long time (over a year) to get it working. Granted, this is no small task, but how much grief did people give Duncan over "v3"? People don't care about how complicated things are; they just want results. ("v3" became Cosm [mithral.com] and is coming along nicely.)

    "normal day-to-day operational work"? Would you outline some of this work? Maybe things have changed dramatically in the past 8 months, but I don't remember any consuming "operational work." I hosted a full proxy -- hell, it was the keymaster for a week or two -- and it took very little overhead from me or dbaker. The ever present stats problems are the only thing that I would say qualifies, but only a handful of people manage(d) stats -- and nugget ignored the work I did on speeding up stats. The most consuming "work" was babeling in #dcti :-)

    Note: I'm not bitter. Despite all of my contributions to the effort (beyond cracking keys), the only mention of my existance is in the ledger [distributed.net] as having donated a motherboard and two NICs -- one NIC burned out and DCTI never used the brand-new motherboard (that I know of.)

  • but if you're using a wide-area distributed computing network, it could make a *lot* of sense

    What about WAN CPU process communication? Lets say I have 50 processers of equal strength on the net working collabratively that were dynamically grouped to do something for a few hours then deallocated for another project. Those hosts all agreed to be on a project of this type and so on and so forth. When is DCTI going to get away from "Hey, its the contest money" and "Hey, this global climate change stuff is neato! Lets let *the people who want to code it* code it and *actually get to use the network and cpu code thats allready done*. It's being done, without DCTI -- and without "day-to-day operations".

    It is called Cosm [mithral.com]

  • er...right. thats what i was saying. interpolation may get you something, but never everything.

    Mills' Theorem sounds interesting...

    --Siva

    Keyboard not found.
  • Obviously you can't factor primes. Prime factoring is the process of finding all the prime factors of a number. Example: 2x2x3=12. Those are the prime factors. I think that is the basic trouble in cracking strong encryption, the type the NSA thinks is worse to export then generally crappy OS's. I'll check my notes first.

Slashdot Top Deals

The biggest difference between time and space is that you can't reuse time. -- Merrick Furst

Close