Cryptohaze.com

only the MD5 algo is currently supported.
So i guess wait abit.

Any ETA till x86/x64 binaries for Windows?

voe01 wrote:hi everyone
I tried to generate NTLM Rainbowtables but all i get is this error:

Hash ID 0 not yet supported!

Any Sugestion?

Wait until I implement NTLM table support I have NTLM table gen working (not released, still in testing), and am working on the NTLM cracking code. Hoping to get that done this weekend, but no promises.

Rolf wrote:Any ETA till x86/x64 binaries for Windows?

"Not any time soon?" I need to rewrite some major chunks of code to deal with the windows version of mmap. Or rewrite the table searching completely to read directly from the file instead of using the memory mapped space I'm dealing with now. Either one will take some time to code and test. Plus I just hate coding for Windows.

Works like a charm since I got it running. I have a few question though, mainly relating to table generation/merging/indexing:

How do we know how many tables to generate and with what chain lengths so that after merging we get high coverage of the password set?

Can we somehow calculate the "completeness" of the tables in a simple manner, ex. multiplying chain length by chains number in a perfect table and comparing it to the number of possible password combinations?

What's the difference (performance-wise) between various bit sizes of the index?

Is reading from a file with multiple hashes a planned feature?

You can download winrtgen http://www.oxid.it/downloads/winrtgen.zip
there is a function in it to calculate success rate in dependence of chain length, chain count, number of tables and so on

read here : http://www.freerainbowtables.com/phpBB3/topic1394.html
and here : http://www.freerainbowtables.com/phpBB3/topic1462.html
and here : http://www.freerainbowtables.com/phpBB3/topic811.html
just browse/search the forum and ask questions if any.

Red wrote:How do we know how many tables to generate and with what chain lengths so that after merging we get high coverage of the password set?

Can we somehow calculate the "completeness" of the tables in a simple manner, ex. multiplying chain length by chains number in a perfect table and comparing it to the number of possible password combinations?

What's the difference (performance-wise) between various bit sizes of the index?

Is reading from a file with multiple hashes a planned feature?

I am working on a web based utility that takes into account the various algorithms present for RTs to do coverage calculation. I'm a bit weak on it right now myself, but getting up to speed on it.

The difference in the index sizes... is something I have yet to fully evaluate. It affects the size of the block read off the disk (as shown when indexing, the average number of elements per index is related to the block size). I've been aiming for something around 20 hashes per index entry, but I haven't fully evaluated it.

Reading from a file with multiple hashes is planned at some point, but that will probably be paid software. I'm still trying to work out how to make this a legitimate sustainable business such that I can fund hardware/justify spending a lot of time on it.

When you switch to a more compact version of GRT where the prefix is not stored for each chain then the optimal index is such that the average number of chains per index is between the size of an index value in bits and half that. So for your current index it is 96 bits (12 bytes) per index value so it would be 96 to 48 chains per index. Since you are storing the full end point this really doesn't matter.

indexedBits = ceiling(log2(chainCount / bitsPerIndexValue))

So that doesn't exactly apply to the current version of GRT but it does apply to RTI2, FRT's current RT format, with bitsPerIndexValue = 8 or 16. The bitsPerIndexValue depends on if you're lucky or not I'd plan for 8 bits per index value which means there are on average 4 to 8 chains per index but if there is an indexed block that has 256 or more chains in it then you need to use 16 bits per index value and restart or be 1 bit per chain larger than the optimal.

will this great software be available for windows or just in linux?

kevinkk5 wrote:will this great software be available for windows or just in linux?

Working on the windows version currently, with a bunch of other tweaks. Windows does not include the Unix mmap command, so I've had to work around that, and I'm working on some multi-GPU and multi-hash code as well.