Cryptohaze.com

foobar2342 wrote:what would be the actual number of hashes? what is the size of the keyspace we are talking about?

It's roughly:
hashes = key_space / ((chain_length ^ 2) / 2) / tables
293 hashes = 2^42 / ((10000 ^ 2) / 2) / 300
21990 hashes = 2^42 / ((10000 ^ 2) / 2) / 4
Rainbow tables are slower than brute forcing (per hash). So that means that these numbers are higher than what the really are. Also that doesn't account for the post work and look ups. It's more like 1/2 to 1/4 of 21990 and 3/4 to 1/2 of 293.

If you have several small tables there is not much difference between perfect and non-perfect. Over at FRT they usually use around a 13x work factor per table and four tables for a total work factor of 52x and a success rate of 99.9%. It's hard to calculate the expected amount of post work even when you have the all the parameters.

Can we keep this on track? Start new threads for discussing brute forcing vs rainbow table tradeoffs...

Sc00bz wrote:

foobar2342 wrote:what would be the actual number of hashes? what is the size of the keyspace we are talking about?

It's roughly:
hashes = key_space / ((chain_length ^ 2) / 2) / tables
293 hashes = 2^42 / ((10000 ^ 2) / 2) / 300
21990 hashes = 2^42 / ((10000 ^ 2) / 2) / 4
Rainbow tables are slower than brute forcing (per hash). So that means that these numbers are higher than what the really are. Also that doesn't account for the post work and look ups. It's more like 1/2 to 1/4 of 21990 and 3/4 to 1/2 of 293.

If you have several small tables there is not much difference between perfect and non-perfect. Over at FRT they usually use around a 13x work factor per table and four tables for a total work factor of 52x and a success rate of 99.9%. It's hard to calculate the expected amount of post work even when you have the all the parameters.

so i change the chainlength to 4096 and then i get 131072 hashes. all i have to do is buy a harddisk for less than $100.
if i have 10000 hashes i only need 10% of the time and 10% of the energy and after some weeks i have the cost for the
harddisk back. you are talking about 2^42 / 10000 which is 2^29 with 32 bytes for start and end value and 4 tables that
makes 64gb. then i can also try chainlength 2048 and i lookup a million hashes.

Progress is being made on this.

After some discussion on IRC, the first revision is MySQL backed - I intend to add SQLite support once it is working (for standalone use). However, installing MySQL isn't terribly difficult, and if there is sufficient demand, I may release a VM image that contains this system (for the free VMWare Server or VMWare Player).

This will be a strictly client/server framework: The server assigns work, the clients process it and return it. No P2P in this iteration.

The basic system structure is coded up, and the "add tasks" bit is nearly completed.

The server daemon will sit and run, connected to MySQL, handing out and receiving work units.

The "add task" utility adds a new cracking task to the database. The system can handle multiple tasks in the queue at once.

The clients will connect to the server daemon & handle work as they can - work will be assigned in a FIFO manner, with the exception that clients will get what they can do - a client that cannot crack SHA1 will not be handed SHA1 work units to crack.

Reporting of status will be done by a separate utility for the most part - this is designed for a nice web interface or GUI to monitor clients.

Support will be present for dealing with untrusted clients. The initial release will be designed for trusted clients (no malicious behavior).

Extending this for new hashes should be fairly easy - I'm building it as a fairly heavily object oriented system, and especially on the server side, much of the behavior is encapsulated in inheritable classes - there shouldn't need to be a lot of "rewriting the wheel" going on.

As always, suggestions are welcome.

Anyone interested in writing a GUI?

maybe a nice addition, which shouldn't be too much work with sql backend:
"work will be assigned in a FIFO manner" , i'd say an option to prioritize tasks would be useful.

That's a good idea, and, you're right, trivial to implement.

Proposed solution:

Default priority is 50. You can pass a priority on the command line for adding a task. Higher priorities mean "do it first."

The ordering then becomes "Priority, FIFO on age." This means that a higher priority task will completely preempt a lower priority task (as clients are available to do it) until it is completed.

Is that along the lines of what you were thinking of?

exactly
it's even easy to change priorities of jobs already in queue now that you are going sql

Good point, the server daemon will automatically implement changes in the priority.

I think that this thread is very interesting, however, the last activity is roughly a year ago. What's the status? Have the project been abandoned, or do you still need a GUI / other stuff?

I got a job, a girlfriend, and a life. This has been a low priority, "As I have time and don't have anything more interesting to do" project.

I'm still working on it, but slowly. Going out camping or hiking with the gf is a higher priority for me lately, as is getting back in shape.

Throw monies my way or suggest ways to monetize the work, and it changes the priorities a bit.