Powered by BOINC

About DistrRTgen

The goal of FreeRainbowTables.com is to give the worlds security experts the best tools available for detecting weak hashes. This can help them to force the developers to use more secure methods of password protection.
By distributing the generation of rainbow chains, we can generate HUGE rainbow tables that are able to crack longer passwords than ever seen before.
Furthermore, we are also improving the rainbow table technology, making them even smaller and faster than rainbow tables found elsewhere, and the best thing is, those tables are freely available to download from our site by anyone!
By installing and running the BOINC client available from http://boinc.berkeley.edu/download.php and pointing it to http://boinc.freerainbowtables.com/distrrtgen/ as the project url, you can help us to speed up the generation even more.
For more information, see www.freerainbowtables.com

Project data

All rainbow tables generated by this project is made freely available as direct download and torrents from FreeRainbowTables.com.


ATI OpenCL issues
It appears similar to the disaster of ntlm, that the md5 OpenCL may have the same issues. I *thought* we had run this algorithm before so it may not be the algorithm but issues with the hybrid2 code. In any case I have halted the production of new work for the GPU side, though there is still work already in the buffer.

I think in the immediate case we have the following to do ASAP:
1) find a way to continue Nvidia CUDA even if we have to disable OpenCL AMD/ATI (or vice/versa) so it isn't a 100% GPU shutdown

2) fix the OpenCL code
I am about to go pick up a new GPU that will let me directly attach vms in my server to the card, such as windows x64. On the GPU side PowerBlade has had the burden of all things windows related, and it is past time that I have a dev environment for both sides. I do have notes in the code for the ntlm side that has a very similar design on the md5 side that might be the issue in both, but I will know more as soon as I can test that directly.

*If* we could come up with a table construction for mysqlsha1 to keep work flowing in the meantime that would be great for crunchers, but we have exhausted the algorithm to a large extent with the code currently deployed. In the mean time work is likely to:
1) dry up
2) erroneously validate in some cases 2 OpenCL results agree (we still do limited checks on the server even with matching WUs)
3) result in a lot of inconclusive results

In any case further updates will be made in as timely a manner as possible. I do not see the time-frame to fix the OpenCL code bugs and get that code out to clients to be more than days.
22 Apr 2014 | 19:08:47 UTC · Comment

Next batch of work flowing for GPUs
First, GPU work is now flowing for NV CUDA and ATI/AMD OpenCL alike.

While, I can make excuses for delays, lack of communication, and so on: everything related to this falls short of the project's goals. First, when work is running low and we do not have the next set queued, we should communicate this. Second, we need to be more flexible for unexpected issues, whether for instance it is lack of developer/admin time or a new set explodes due to errors, we need to not just be ready for our next set but the set after that.

Communication is something we need to have at the forefront. On the admin side we have graphs, monitoring, and predictive stats for when work will run out *but* this seems to fail and the reason is simple: we are overly optimistic about the times to test and push a code fix *or* are struggling to use existing deployed code to create useful sets that are not so large and slow as to be unusable.

In this particular case there is a bug for the AMD/ATI OpenCL code for ntlm which resulted in the matching mysqlsha1 set that just wrapped up. I believed I could get this code fixed, tested, and deployed in a timely fashion, but should have just released the md5 set that is now in progress. I *thought* we had already done the md5 set as well as being optimistic on fixing the OpenCL bug on ntlm. This batch *should* have and *could* have been released to prevent any interruption in the work flow.

I made a placeholder thread, which I will expound on this, including making excuses in the primary forums https://www.freerainbowtables.com/phpBB3/viewtopic.php?f=4&t=4658
22 Apr 2014 | 1:17:07 UTC · Comment

GPU work now flowing
First, my apologies for the overly optimistic time frame. We had to push out some client changes and handle a server side change prior to work distribution for the next 4 tables.

Also, if it was not noted before, we have CPU work flowing again as this didn't involve any client or server changes.

The GPU work units are on a faster algorithm than the mysqlsha1 and the per workunit uploads will be roughly double in size, but are likely to run for a similar length of time as the last 4 tables. Credits take into account both the algorithm and number of chains in a work unit and have been scaled along with the other parameters.
21 Sep 2013 | 17:55:04 UTC · Comment

project work
We ran out of work to hand out and are putting together what tableset to do next.

We hope to make decisions and get this pushed out within the next 24 hours or so. This next batch is planned to be mixalpha-numeric-all-space-{Nordic,German}#1-8 where the Nordic and German characters aren't fully decided. Depending on selected characters and other parameters this will result in 4 tables that should take a total of 90+ days.

Potential characters:
We won't be able to include all of those so any feedback from native speakers on which are most common is appreciated. Responses here or in the phpBB forums (https://www.freerainbowtables.com/phpBB3/viewtopic.php?f=11&t=4580) are welcomed and appreciated.
18 Sep 2013 | 21:52:05 UTC · Comment

gpu work queue and recent issues
The GPU side queue ran dry on Friday and in our haste to fill them, encountered some additional speed-bumps. Please see my post for more details. 19 Nov 2012 | 1:11:22 UTC · Comment

... more

News is available as an RSS feed   RSS

Copyright © 2015