Slashdot Mirror

← Back to Stories (view on slashdot.org)

Distributed.net releases CSC and OGR clients

Posted by Hemos on from the crack-yet-more-blocks dept.

NIVRAM writes "After six months of waiting, Distributed Net has finally released beta clients for CSC and OGR cracking. They can be found here. (Looks like 'a few weeks' took a bit longer, eh?). For those of you who don't know, distributed.net is a non-profit group which uses the power of many computers to crack large encryption algorythms such as RC5 and the U.S. Government's DES. "

11 of 92 comments (clear)

  1. Re:other contests? by NIVRAM · · Score: 2

    If you have the new client, you must tell it to grab keys from the proxies listed at the beta page, otherwise it will only get RC5 blocks.
    I use beta.dcti.org:2064... but there are some other non port 2064 ones listed.
    Have fun and happy cracking.

    NIVRAM

  2. Re:Uh huh by NIVRAM · · Score: 2

    Read carefully about what happens to the money. It doesn't go into the D.net staff pockets, it goes into the D.net network, computers, etc etc. Dbaker and Nugget and all the people are not in it for the cash.

  3. combo client by peter · · Score: 2

    Too bad there isn't a project which uses floating point. If there was, they could write a client that interleaves floating point with integer calculations to _use more of your computers brain at once_ :) (Pentium CPUs (and others, but I haven't read as much about them) have multiple execution pipelines, so they can start a floating point pipeline working on finding the cosine of something, while the integer pipelines carry on running instructions at full speed. The CPU stalls if some other isns need the result of the multiply before it is done, of course. I think the most recent (PII and PIII (oh yeah, celery too), k6-{2,3}, and k7) all can all have floating point insns running at the same time as integer. I may be wrong on this one. Maybe the x86 doesn't have enough registers to make this work very well though. Oh well, I think the G3 and G4 all have kick ass stuff like this, too. And then there's Alpha. :)
    #define X(x,y) x##y

    --
    #define X(x,y) x##y
    Peter Cordes ; e-mail: X(peter@cordes , .ca)
    1. Re:combo client by icing · · Score: 2
      You are right about the processor's capabilities. However multitasking operating system have a hard time to support this.

      When you have two processes running, A and B, then all processor registered are saved and restored when the OS switches from A to B and vice versa. Otherwise they would step on each others toes.

      But maybe one could write a "virus" which infects non FP-using programs and lets fp calculations run during programs execution time?

    2. Re:combo client by Greg+W. · · Score: 2

      Too bad there isn't a project which uses floating point. If there was, they could write a client that interleaves floating point with integer calculations to _use more of your computers brain at once_ :)

      Many of the distributed.net cores already use a combination of "normal" and MMX instructions to achieve this effect. Unfortunately, the d.net mailing list archive doesn't appear to be searchable, but I did find some preliminary analysis of an Athlon core which would derive similar benefits (read: chew through keys like a crazed wolverine on crack :-) ).

      To "icing": your analysis of multiple-process issues isn't relevant here -- we're talking about a single execution thread, so there's no context switching. (What you said was true of course, but it just doesn't apply in this situation.)

  4. OGR searching by mjg · · Score: 2

    It's nice to see more support/availability for the OGR project. IMVHO this is one of the most useful distributed projects around at the moment. While proving that you can crack RC5 might be fun, it doesn't have a real pay-off at the end, except for the small prize monies. The same goes for SETI@Home, which is a needle in a haystack search for something which may or may not exist.

    Of course, OGR is probably also the least exciting to participate in for most people. At the finish of it you have something which is useful (to some people), but hardly greatly exciting for anyone outside of the field. On the other hand, producing a result confirming extra terrestrial life from the SETI@Home project would be interesting or exciting for almost everybody. This is probably the biggest reason (along with the differences in publicity) why more people support the less-likely-to-return-something-useful projects like SETI@Home over something like OGR or GIMPS.

  5. RC5-64 is certainly not brute force safe by copito · · Score: 2

    Distributed.net has been cracking RC5-64 for 2 years and has exhausted 15% of the keyspace. A computer 100x as powerful (which is not far fetched if you assume a hardware based solution similar to Deep Crack from the EFF) could brute force the keyspace in a few months. That's not a very large margin of safety since the brute force attack can be trivially twice as fast if you spend twice the amount of money on it. If you assume a brute force attack combined with a cryptanalysis attack, you could be talking days or hours instead of months.

    At this point you are banking on the fact that it still would cost a considerable amount of money to build a fast RC5-64 cracking device, probably between 1 and 100 million, and that the benefit of decrypting your transaction is much less than that. Since much more powerful codes exist, it seems silly to take that chance.

    --

    --
    "L'IT c'est moi!"
    1. Re:RC5-64 is certainly not brute force safe by copito · · Score: 2

      Deepcrack was 80Gkeys/sec, the peak rate of the rest of D.net was 170 Gkeys/sec. So Deepcrack was half as fast as the rest of D.net. Not bad for $250,000. So you see that for $100 million it could be trivially 100x as fast as D.net. I would suspect that $100 million gets you a better design to boot, but with government procurement, it might get you much less as well.

      Unfortunately getting stronger crypto is not a function of Moore's law, since clearly "unbreakable" crypto with 128 bit symettric keys or 4096 bit public keys is well within the reach of modern CPUs. It is much more a function of inflexible legacy systems or protocols and assinine government regulation.

      You make a good point that security is a time sensitive issue, but for me a few months is a not a good enough margin of safety for any crypto, since there is always the possibility that somebody is 10 times smarter, faster, or more determined than I thought they would be. A few months quickly becomes as few days or hours. I am much less worried where the theoretical margin of safety approaches the age of the universe. Since this is possible with modern crypto and large keys, I see no reason not to go the extra mile.
      --

      --
      "L'IT c'est moi!"
  6. Why casino-21 is better... by homunq · · Score: 2

    Cracking codes doesn't really accomplish anything more than proving a point. (Unless you're a government - but since WWII, government codebreakers are mostly the bad guys).

    Yes, OGR's actually have some practical use. However, they're only the optimal case of Golomb Rulers, and it's pretty easy to find near-optimal ones - only a couple percent off, at worst. Worse, for any given application, the number of marks that is desirable is bound to increase linearly. Any non-QC method of finding them will fall behind over time, even supercharged by Moore's law. (And the problem with the quantum solution is that it doesn't distribute. 2 128 bit QC's FullOn3d claims. Also, until they have an algorithm that would spot the earth, the chances are miniscule.)

    Then there's Casino 21. Cooler graphics, actually useful. On the down side, it's vaporware (no pun intended) and it requires more serious hardware.

    O=C=O O=C=O O=C=O O=C=O O=C=O O=C=O O=C=O O=C=O
    But really, if any of this stuff gets you to leave the computer on overnight when you wouldn't otherwise, it's doing more harm than good.
    O=C=O O=C=O O=C=O O=C=O O=C=O O=C=O O=C=O O=C=O

    (although I'm kinda waiting for the day when you can use spare cycles to stress-test beta software. The only problem with that idea currently is that bad software will more often than not bring down your OS with it. At least, with most OS's :)

    --
    Preferential Voting: easy as 1-2-3
  7. Comment removed by account_deleted · · Score: 2

    Comment removed based on user account deletion

  8. Anyone have the details of CS-Cipher? by Paul+Crowley · · Score: 2

    The CS-Cipher description isn't properly available on their Web pages: they require you to turn on Javascript and register before you can fetch the description, and their registration form is broken.

    Words cannot describe my contempt and loathing for the unutterably rude people who hide information they should be making freely available behind registration forms, or JavaScript, or worse both. That their form doesn't even work just shows they're incompetent as well as stupidly unpleasant; the two often go together.

    Anyway, so, anyone know a perfectly ordinary URL where a description can be found?
    --

    --
    Xenu loves you!