Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

Distributed.net releases CSC and OGR clients 92

Posted by Hemos 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. "
This discussion has been archived. No new comments can be posted.

Distributed.net releases CSC and OGR clients More

Distributed.net releases CSC and OGR clients

Comments Filter:
  • Its just nice having a group out there breaking these keys, better them now then a foreign country later.

  • And start crunching on CSC and OGR blocks while I keep doing RC5 so my rank increases! :)

    CSC and RC5 are at least real contests---OGR is nice, but I'll work towards the monetary goal, thanks.

    -Chris
  • Clients are out for Win32, Mac, and a few other platforms.. the link to the page has the list.
  • the client is set up so that it does work for shorter contests before it does RC5. Mine is cracking RC5, so does that mean there are no other contests at the moment?
  • But... rc5 has not finished, has it?
  • 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
  • Mine defaulted to RC5, I don't think they have started the new contests yet. Anyone know if they're going to start up new stats for all the contests, or integrate all the stats for each contest into one "megastat" rating??
  • That doesn't mean D.net won't be working on other projects too, does it? In the clients, you can select which project you want to give priority to. For you stats freaks, you can stick with RC5. Me, I'll try CSC and OGR if it'll help the great guys at D.net make things go more smoothly.

    NIVRAM
  • No, nor will it finish anytime soon. RC5-64 can pretty much be assumed to be brute-force resistant. They're still in the low percentages of the total keyspace and they've been at it for AGES.

    Brute force only being one method though. Algorithm weakness is a different matter entirely.

    Lucklily, even if we assume a 3 letter gov't group somehow has 10 or 100x the power of all the distributed.net computers and deepcrack, etc, you can still assume RC5-64 to be brute force safe.
  • 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.
  • Am I the only one that finds it amusing that this story shows up just after one entitled "Expanding Vulnerability of the Net"....?
  • 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
  • There must be some other uses for the incredible power of the megasupercomputer that distributed computing creates. I mean other than just cracking the latest encryption algorithm(s).

    I'm sure someone will come up with a new and cool use for Dist. Comp.

    --krahd
  • The download page (for RC5 at least) says "The binaries and source here are the ONLY ones you should be using," but I can't find the source packages.
    I don't trust programs that upload and download packets without my direct and complete control.
    Unless they open the source, my paranoia will prevent me from participating.

  • 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.

  • Did you remember to set
    keyproxy=beta.dcti.org
    in the [parameters] section of your .ini file?
  • I agree and I hope somebody does do it soon. I see no reason what is acomplished by proving to ourselves that we can do something that we know we can do anyway. Is this the have to touch the pan that your mom tells you is hot for you to know it is hot thoery? I honestly dont understand the whole point in dedicating so much to cracking these keys. Isnt there something else out there that we all could be devoting our CPU time to?
  • I know, setup up a rendering/raytracing client, so those wanting to play around with making movies with CGI scenes have a way of getting things done sooner...
  • 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 [eff.net]) 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.

    --
  • heh

    good call
  • It's great to see many more distributed efforts going on! Imagine a completely network distributed operating system, where idle NC's are given tasks to complete for distributable calculations. Does anyone know if anything like this exists? The protocol would have to account for things such as network bandwidth and saturation, as well as the capabilities of participating NC's.

  • 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 [fullon3d.com]. Also, until they have an algorithm that would spot the earth, the chances are miniscule.)

    Then there's Casino 21 [rl.ac.uk]. 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 :)
  • all you lynx users will have noticed that following the posted link to the d.net/beta/beta.html gives you a Alert: Location URL is not absolute! message, and you lose. Their web server is returning: "The document has moved here [beta]" in its 302 Found reply. I've mailed them about it, so don't slashdot their mail server. (I'd like to think that all the /.ers who use lynx add up to something :)

    The actual URI that you get to is: http://distributed.net/beta/

    (I was going to post this as HTML, so I could make the real addy a hyperlink, but slashdot doesn't allow , and I didn't feel like quoting the interresting part of the first paragraph. curse you slashdot :) Oh this is even better: If I preview with lynx this message as plain text, my pre tag is interpretted as HTML. maybe this is lynx or maybe this is slashdot. watch this: notice that there is a pre tag embedded before just before this sentence
    #define X(x,y) x##y
  • SETI *is* kinda like searching for a needle in a haystack.

    Only... we don't know what the needle looks like, where the haystack is, or what we'd do with the darn thing once we've found it!

    Crack RC5-64! Why? Cause its there and begging for it and we'll know when we've found it!

    later,

    Ben.Scherrey@ga.lp.org
    Ranked 8297th and climbing!
  • The beta keyserver is beta.dcti.org. www.dcti.org gives the same page as www.distributed.net. When was the change made (or is this just another test thing)?

  • This is a directive to all /. linux/bsd/UNIX proponents (of which I am a member.): Do not start a big thread here. We all know that a Real Operating System will not be brought down by anything unless it is run by root.

    to keep the raving masses happy, I will try to say what everybody will say. (gee, this is sounding really bad. I'm not trying to censor people, just to stop them wasting their time raving about Linux. sorry.)

    Anyway, most operating systems use various schemes to stop random users from bringing down the machine. Most sensible OS designers see the ability to crash the system as a Bad Thing. Only the superuser should be able to do that, and even then only be explicitly using interfaces to the stuff that should be mucked with carefully. There are a couple of "modern" OSes which don't live up to this standard, but the majority of OSes don't crash easily from bad programs. The program goes down, but it cant touch the rest of the system. You should look into this sometime, if you find that your OS does let itself be crashed easily.

    oh yeah, and tux rules, so does devil dude (whatever the BSD mascot is called).

    If you are really concerned about not crashing, there are several things you could do. Most are well known and rational, but some aren't [satanic.org] :)

    If I screwed up some here, then I won't be mad if you post more in this thread. Just this is not the place for _another_ OS flameout.
    #define X(x,y) x##y

  • thanks for that great link to localhost. They have some great software on there. It looks a bit like what I've got on my machine already, but its still useful in case of a disk crash. :) &lt grin &gt
    #define X(x,y) x##y
  • No, nor will it finish anytime soon. RC5-64 can pretty much be assumed to be brute-force resistant. They're still in the low percentages of the total keyspace and they've been at it for AGES.

    I would have to respectfully disagree. With a couple of notable exceptions, the distributed.net attack on RC5-64 (and before that, RC5-56) has been growing quite quickly. I remember participating in the RC5-56 contest when the estimated time to completion was in the decades. Moore's Law and a word-of-mouth spread of participants has caused it to rise dramatically. For an example, take a look at the distributed.net statistics at rc5stats.distributed.net [distributed.net] and compare the current keyrate against the average. It's more than double! Also note the "The odds are 1 in 1,680 that we will wrap this thing up in the next 24 hours." So that's 1 out of 5 years, but a simple doubling of computing power over 18 months means 1 out of 2.5 years, and another doubling 1 out of 1.25, etc., even if you don't count the keyspace exhausted while waiting for the doubling to happen. Add that to substantial growth in participants, and you have a solution in probably 2 years.

    I know, it's a long time, but this is using completely idle cycles and general purpose hardware and volunteered programming and organizational ability. A full-time project with the funding and wherewithal to develop custom hardware (along the lines of EFF's "Deep Crack" machine for DES [see http://www.eff.org/descracker.html [eff.org]]) would be able to crack RC5-64 fairly easily. RC5-128, probably not.

  • Re:Cool (Score:1)

    by peter ( 3389 )
    all they do is break a single encrypted message. There is no way to use the work done by the d.net distributed computer to help break any other encrypted message, even using the same encryption algorithm (not key!) You can make use of the the work done by the d.net crew because the source for the cores are available for free.

    Maybe your point is that it is good to realize that rc5-64 is not all that strong. If that's what you mean, then you have a good point.
    #define X(x,y) x##y
  • 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?

  • There's a good reason for that - it prevents people from writing their own versions and mucking with the results. Again, as we've learned from Microsoft, anything you don't inspect and compile yourself can be dangerous, so it's a risk you need to take...





  • I'm still waiting for _any_ of these cracking clients (or preferably SETI) to start to support the G4's Velocity Engine. Sure, I'm running things pretty fast as they are, but still wouldn't mind an optimized client...
  • While the other two responders to your post have made good sense, I think they miss the point: The CORE is open source. You can see what the client is doing, exactly. The CLIENT is closed so that you can't trap the winning key, turn it in to the RSA yourself and collect the whole 10,000 - leaving D.Net out in the cold!

    Open Source is the answer, just not to this question...
    "I have no respect for a man who can only spell a word one way." - Mark Twain
  • Not to be redundant here, but there is a good reason that the client source is closed.

    The client source is closes so that some clever programmer doesn't write a client that tells HIM what the winning key is first, allowing him to submit it to the RSA and walk off with the entire 10,000! This would NOT be good!

    The CORE to the client IS open source - you can even compile it! If you want to know EXACTLY what your machine is doing, download the core source at http://www.distributed.net/source/ and check it out for yourself! While you're there, could you write a core for the K7? I've looked at it, but it's a tad beyond my meager programing skills.

    Open Source IS the coolest thing since sliced bread to be sure, but it's NOT the answer to everything in the whole wide world. This is a clear exception to the "Open Source is Better" rule.

    "I have no respect for a man who can only spell a word one way." - Mark Twain
  • Comment removed based on user account deletion
  • 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?
    --
  • We're using beta.dcti.org to avoid confusion with our production network. We want to make sure everyone realizes that this is only a betatest, and that all the blocks done by the beta clients will eventually be discarded.
  • Ok... Right from the source: We know that security by obscurity is not the best solution to the problem, however, we have not been able to find a good solution that will allow us to go entirely open source. We are happy to take suggestions though, so if you have any good ideas on how we can go entirely open source and still be confident in the return packets, we would love to hear.

    --
  • Just out of curiosity, why start another distributed effort competing with distributed.net on the same contest? Why don't we all join one effort, and find the key quicker instead?

    If any dcypher people are reading this: what's the reason behind this effort? D.net has a gazillion participants (well, some 50 000 active ones, at least), and will thus very likely find the correct key before any new effort (unless, of course, all those d.net participants continue to run RC5 instead of CSC). Not to mention that d.net already has released linux and freebsd clients, and d.net's clients are at least partially open source..

  • 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 [distributed.net] 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.)

  • As you can see here [distributed.net], the bulk of the money will go to a non-profit organization as decided by the distributed.net participants. When we do begin CSC officially, an equivalent voting board will determine the distribution of the prize money as you see here for RC5-64.

    As you can see from the public ledger [distributed.net], distributed net has donated almost US$20,000 to selected non-profits such as EFF [eff.org], FSF [fsf.org], and Project Gutenberg [promo.net].

    What money we have retained has gone directly to supporting the network and buying necessary equipment, and not to staff.

  • I keep hearing the same drivel over and over from the d.net camp so it's only fair that you get to hear my drivel over again.

    If a company tries to sell a Slashdotter a closed-source encryption package, it doesn't get very far. The reader knows that if the package has holes that could be exploited by reading the source code, then the package has holes that can be exploited by reading a disassembly.

    Why can't the /. readership apply the same logic to d.net as they apply to everything else? Is d.net somehow excempt?

    If you couldn't be "confident in the return packets" if the full client source were released, then the only way you can be confident now is if you're deluding yourself.

    I'll probably get flamed just like the last time I dared voice a negative opinion about d.net, but fuck it. If you're inconsistent while flaming me, the flames only make me stronger.

    To prevent misunderstandings, let me state the nature of the holes I'm talking about. I'm not talking about running the d.net client compromising my security by it sending my passwd file to d.net or something like that. I'm talking about vulnerabilities that destroy our confidence in the results of the key tests.

    Perhaps I just have the wrong take on the whole thing. I've been viewing d.net as an experiment and exercise in making trustworthy machines out of a mix of trustworthy and untrustworthy parts. But I believe this is one of the goals of the d.net project and that I'm not just pulling this out of my ass. It is not true that the d.net system is just a system for collecting a $10,000 prize and proving the need for longer keys to the US govt, whichever haphazard gum-and-shoestring method it takes.

    I'm with grandma on this one: If you can't do it properly, you might as well not do it.
    --

  • I tried SETI but I just felt that it would never find anything. Right now I'm going with RC5 but I may well switch to OGR.

    Specifically I think the criteria for a good project are:

    1. Has a definite finish (i.e. check x keys, y OGR tails, z amount of SETI bandwith).
    2. Finds something new and intrinsically interesting (RC5 fails here, since the solution is just a random bit string... wheee!)
    3. Is guaranteed to have a solution (SETI fails here -- finding nothing proves nothing)

    That being said it's hard to find a good fit for these rules. OGR comes close but I think it lacks mass appeal.

  • Re:Trying again (Score:1)

    by Anonymous Coward
    Howdy, Me Again. Okay reasons for not being open source at this very minute. NO TIME. Quite simply we are too busy to fsck with a license that open sources the client and protects us at the same time. As for why we are starting this: Have you noticed how slowly d.net moves from one porject to another. Totally unaccpetable in a commericial environment, and we want to start running projects which are commerical in nature (I.e. large simulationg for large companies, etc.) and actually PAY users for their spare computing time. Steve
  • Isnt there something else out there that we all could be devoting our CPU time to?

    Sure there is. Devote your idle cycles to SETI@Home [berkeley.edu] (Search for Extraterrestrial Intelligence).

    It has been talked about numerous times in the past on /.

    Personally, I do not belive that searching outer space is more productive than making it known to the powers that be that the current encryption algorithms are inadequate and should be replaced by something stronger -- like rc5.

    -d9
  • I've been running RC5-56/64 for about 30 months now. When I found OGR a while back, I started splitting my CPU time 50/50 between that and RC5. More work on my part to get work units, but it seems like a more worthwhile goal than RC5. Not that I think encryption isn't something that we need to push to be stronger, but we've spent 2 years now to find out "hey, this is really hard" and, well, I like to see SOME real results from my efforts. Now that OGR is thrown in the mix, and it's going to be relatively hands-free, I'll be switching to that project, or splitting my time 75/25.
  • I currently run SETI on 4x P3-500mhz and RC5-Client on hmm 45 x 300-500Mhz PII-PII (GUI Version!). And now i read about a new Client and want to Download it AND? No GUI Version available???!!! Sorry, no GUI!, no Client!. I hate nonGUI Versions so i run me old GUI as long it works and then i say GoodBye to RC5 and install SETI on all Stations. And for the CSC and OGR Clients i can only repeat no GUI! = no Client! They should consider to release a GUI Version of them i'm sure that many People out there will not install a nonGUI version for some good Reason. Its a Problem anyway that SETI came because now i love SETI more than the RC5 thing so if things turns Bad for RC5 like new CLI versions are incompatible to GUI versions or so RC5 is dead for me. Beside the GUI Troubles where are the PIII optimized Clients anyway? What i can't understand also is that it takes so long to break a 64Bit RC5 Key thats only 8 Bytes not very much?! I use Keys of 8KB for me Ciphers thats Big but Bytes and in RC5 there must be some weak points or why else they have allready RC6 out?! Moooooo.... :)
  • Something else to keep in mind is the ability to keep up with demand. SETI@home fails on this one. Not sure if they are still doing this, but for a while there they were sending out duplicate work units because they had more processing power than work units. RC5/64 definitely does not have that problem. Over a year and only 10% of the keys have been checked?

    SETI are scanning a relatively limited frequency spectrum, which means that there might be a message out there and we are listening on the wrong station.

    I am also waiting on a G4 RC5 client (along with my 2nd. processor for my Umax clone).

    In related Distributed.net news, I sent in an email to DBaker telling him that they should get shirts from Copyleft.net (for more information on this, read his latest plan update). I, for one,emailed him about it, so don't fill up his mailbox.

    Anyone else have problems with keys sent in Sunday/Monday? I sent in about 200 keys and got credit for 8 of them.

    Anyway, enough random distributed thoughts.

    (c) 1999 Hank Zimmerman
  • In saying that SETI@Home is more worthwhile, you make the assumption that there is actually something out there to find. There's almost no chance of that.
  • I meant my "most OS's" comment to be a slam at Win32 and MacOS. The smiley meant "Of course we all know linux is better". Truth is though, most spare cycles are still owned by technically deficient OS's.
  • Just wondering if you have checked out the newer versions of the distributed.net win32 CLI? its alot more "GUI" than it used to be. It iss a windowed app, you can copy from the window, right-click menus to configure, benchmark, fluch, fetch, update, restart, pause, shutdown. It even has an about box now that you can copy the client version info from.

    So if you haven't tried it out lately, I would suggest checking it out. If you have and you still don't like the client, I'm sorry. You are more than welcome to contribute to other contests and projects, after all it is your computer time, but I am sorry to see you go.

    Thanks for the time that you have given so far.
    Moose!
  • I find it rather curious that there is a post about a beta starting up and no word about a project aimed at the same goal with finished software going up.

    I find it curious that you didn't bother to name the project or provide a link to it. Is it the CSC one that's already been mentioned earlier, or another (possibly OGR)?

  • The lack of source hasn't prevented that in the past. However, if the source were public, then there would be many more "idiots" flooding the network -- it would appear some people have nothing better to do.

    Actually, I'm surprised someone hasn't disassembled the buffer processing code, yet.
  • from what i understand isn rc5 opensource? i heard only the networking part was closed source. So conciveably you could write your own math section and link it with the network module? please correct me if i'm wrong.

    matisse:~$ cat .sig
  • "why more people support the less-likely-to-return-something-useful
    projects like SETI@Home over something like OGR or GIMPS.    "

    finding extratresstrial life would be one of the most signifigant things every accomplished by mankind. Cracking a freaking code isn't nearly as signifigant. Now if they'd let us work on cracking the human genome, that'd be a little more important, but for me i'd rather search for aliens than find OGR. However because of the fact that the arecibo dish is overloaded, i am not helping(doing GIMPS). However if they ever get another dish i'd go back.

    matisse:~$ cat .sig
  • You're forgetting what this article is all about.
    OGR has practical applications.
    And Seti@home has the cool benefit of potential contact with another species.

    But yes, more applications would be nice.
    Of course, the more out there, the less processing power each gets... :)
  • 2 points.. First, building a computer 100x stronger then all of D.net would be difficult at best. Was there not a deepcrack machine at the last DES test? It was strong, yes, but it still didn't have the power of D.net. These machines both benefit and suffer from Moore's law. They get faster as time goes on, but by the time you've invested and built one of these ubercrackers, it's not the best solution, faster systems and stronger crypto would be the norm.

    Second point, the time it takes to brute force something should be taken into consideration when encrypting the data in the first place. If you have data that only needs to be secure for a month before it's a moot point, then you can say RC5-64 is good enough.
  • No, no other contest has been started at this moment. These are beta clients....the bugs are being worked out before the contenst(s) go live.
  • Yes, I sent the post in. I don't personally know anyone who works with Slashdot's page. I submitted it because I thought it was an interesting project and I wanted to make sure the readers of Slashdot knew what was goign on. You're free to send in posts, as far as I know, about generally anything. From what I've seen with Slashdot so far, they're fairly impartial as to which stuff they'll post. Don't make me out to be some sort of friend of the Slashdotters, I'm just a Distributed.net supporter and I want to express that

    NIVRAM
  • If you're in it cause theres a prize, you're prolly in it for the wrong reason. Do you think people who use D.net clients care that they may win some money? For the most part, I'd have to say no. They're in it because it allows them to give to a good cause without much hassle on their part. I could care less how much prize money was offered, I support D.net because unlike some causes, they do it because it needs to be done, and because its all around fun. Why don't you come into #distributed on EFnet sometime, see what the project is all about.
    No, I don't help run D.net, I'm just one of the many thousands of users, and I like to voice my opinion.

    NIVRAM
  • Yes, the 'core' is open source, and we love it when anyone sends us any patches to the cores that increase their speed.

    Using the FPU in parallel is something that has been tossed around (along with a 'core' for video cards and printers), but no work has been done that I'm aware of.
  • As far as I understand it, it would be pretty difficult to rip out the core and leave the networking intact, and replace the core. The core is open source, but since the rest isn't, there's no easy way to plug in a new core.
  • I'd tend to agree with Moose here, I used to run the GUI's, then switched to the CLI's over the last couple of builds. Frankly, the old GUI and the new CLI are very similar. I think the only major graphical difference of any consequence is the log viewing, thats why the new CLI has a log viewer app. But again, if you don't want to use it cause it says CLI, then good luck with your SETI projects. Re's to Moose.

    NIVRAM
  • Kudos to you for starting your own project. Personally, I'm still quite happy with D.net even if some of the people get annoying at times. The D.net ops are easy to work with and very helpful. I'll stick with the project I know is working for the cause I support. D.net's been around for a while, and will continue to be around. Best of luck on your venture

    NIVRAM
  • 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.
    --

Slashdot Top Deals

We gave you an atomic bomb, what do you want, mermaids? -- I. I. Rabi to the Atomic Energy Commission

Close