Dear friends,

After three years of effort, we have passed the half-way stage of this ground-breaking project. We thank you for your continued participation.

Moo!

Dear friends,

With 2010 coming to an end, we thought this would be a good time to review the tremendous progress we’ve made this year, particularly on the RC5-72 front.

Modern video cards now typically include highly advanced parallel processors that can sometimes be used for general purpose computing. Although only certain types of tasks are currently suitable for GPU acceleration, we’ve found that RC5 falls happily in that category.

We began beta testing our first GPU-based clients for nVidia CUDA and ATI Stream in January and February 2009, respectively. Public testing of the GPU clients continued for about a year until we officially released both the CUDA and Stream clients in January 2010.

Adoption of the new GPU clients has been very successful throughout 2010, due in part to the folks at DNETC@Home. At this moment, about 86% of our incoming completed RC5-72 results come from Stream clients, 5% from CUDA, and 7% from traditional x86 processors.[1] Another exciting milestone is that the overall total results ever received for the RC5-72 project, results from Stream/Win32 are extremely close to surpassing those received from X86/Win32, despite the nearly 7 year lead before the official release of GPU clients.[2]

RC5-72 keyrate for 2009-2010

At the end of 2009, our overall RC5-72 project keyrate was about 250 GKeys/sec. Our current project rate is now about 1.5 TKeys/sec, or about 6 times faster than last year!

If we started RC5-56 right now (which took us 250 days in 1997), and found the key in the same place as last time, it would take us about 18 hours to complete. If we had to check the entire keyspace… it would be a little longer–perhaps 38 hours!

In the coming year, we hope to announce some other exciting developments which should continue to push the performance and awareness of distributed computing.

If you’re on Twitter, be sure to follow us on @dnetc!

Happy Moo Year!

Dear friends,

We recently received the first true “false positive” work unit of the RC5-72 project. These are a rare find.

In the interests of client speed, only the first “block” of the encrypted text is decrypted and evaluated for a solution. This means that it’s possible for a key which isn’t the correct key to report as a false positive because although it doesn’t decrypt the text, it does yield a plaintext which matches “The unkn” for the first eight bytes.

The decrypt of the packet was “The unkn…O.k.V>..3W.R..lW.]*e.sc.:-…..u…..cN.&.0.N.” The lucky participant is known as 門村 (“Gate Village”) and will be receiving a T-shirt from us soon. He is a researcher in Japan running dnetc on a Windows system with a Stream client.

As some participants may recall, we also identified a similar ‘false positive’ during the previous RC5-64 project. Finding these are exciting because they help to validate that the project is working properly and is still on track to find the real solution.

It also represents an interesting datapoint regarding the RC5 algorithm. There’s been much speculation and napkin scribbling on just how frequently such false positives might present themselves. The general consensus seemed to be that such an occurrence is extremely improbable. A brute-force search is really the only way to conclusively determine the likelihood of such false positives.

Keep on crunching!

If you’ve been following our OGR-27 stats you’ll have noticed we just passed through 12% completion. We’re steadily marching forward at rate of approximately one percent a month thanks to our contributors and welcome everyone to join in.

:: 04-Jul-2009 12:26 GMT (Saturday) ::

Dear friends,

Since work began on OGR-27 in late February, more than 2% of the total work
necessary to prove OGR-27 is not optimal has been completed.

The first three stubspaces are nearing completion, and should be closed in
a matter of days. During this time, we will be periodically recycling the
remaining stubs from those three stubspaces, so it is important to avoid
excessively fetching more work than you can complete in about a week.

We have just started distributing work from the fourth and final OGR-27
stubspace. It is also the largest stubspace representing the remaining 98%. The
stubs in the final stubspace are more likely to vary greatly in size, compared
to those in the earlier stubspaces; however we expect them to generally be
smaller on average. If our estimation turns out to be proved correct, we should
be able to complete the remaining stubs at a faster rate than for the previous
stubspaces. As we are expecting that we will discover a better ruler for OGR-27
than the one we currently know to be optimal, we may not need to exhaust the
entire stubspace before discovering it. However, after the probable discovery
of a better ruler, it is possible that there remains an even better ruler or
rulers yet to be uncovered.

In addition, thanks to some excellent work by Craig Johnston, client versions
2.9105-510 and above contain three new OGR cores. Depending on your CPU type,
the new cores may provide a significant speed improvement over the cores
used in previous client versions. These speed enhancements will shorten
the time required to search the final stubspace. You are welcome to try a
pre-release client containing these new cores, which you can download from
http://www.distributed.net/download/prerelease.php. As always, please report
bugs using our bug database available at http://bugs.distributed.net/.

So load up those CPUs with fresh OGR-27 work, while enjoying an improved
noderate, and together we’ll crunch through the final stubspace with fury!

Thanks again for your participation!

Moo