Not to mention the uncracked hash stats. Speaking of, it seems we need to add some algorithms: mysqlsha1 and sha1.

Ok, here are some very basic stats on reading RTs from an USB stick. Corsair 8 GB and Intenseo 16 GB seem to be as fast that running an OS, current kubuntu and BT4, doesn't really feel that much slower than booting from disk. Startup time is rather different, though. So here are the results with one set from lm_all (11GB) on an Intenseo stick:

Just reading tables from the stick (msi wind U120):
=> 10 LM-Hashes against one set (0) from lm_all:
=> 23 Minutes, no hash in the table

Booting from the stick (BT4 on a Dell D530):
=> 10 LM-Hashes against one set (0) from lm_all:
=> 15 Minutes, no hash in the table (using 2 cores)
- Disk access time according to racki_mt: 30 seconds (??)

However, 4 GB is really thight for BT4, this leaves no room for any but the most simple modifications. So aiming for a table that fits into 10 GB (for a 16 GB stick) might work just as well. That'd leave ample room to install things. With 4 GB, the space was just enough to install rcracki_mt. Oh, and it complies w/o hassle on BT4.

The times rcracki_mt gives are a bit off from reality as you noticed. It's on my todo list.

ophcrack sells Vista Nine table set:
Success rate: 99%
Passwords of length 8
Charset: 0123456789abcdefghijklmnopqrstuvwxyz with the first letter capitalized
Passwords of length 9
Charset: 0123456789abcdefghijklmnopqrstuvwxyz

I sure hope that most domains has turned on the option for enforcing strong password policy in Windows, which requires 3 of character groups to be present in the password, and the passfilt.dll implementation from Microsoft itself requires minimum length 6. The length option here is irrelevant though, since most organizations are using length 7 or higher in their policies.

However, a consequence of this is that 50%+ passwords become alphanumeric, with first letter capitalized. So a NTLM RT with length 9 is most welcome.

Regards,
tittentei

http://securitynirvana.blogspot.com/

We have ntlm_mixalpha-numeric#1-8, more complete than the ophcrack length 8 you mention, which weighs in at a hefty 423GB and the success rate is higher than 99.0% but I don't have the exact number (and am too lazy to do the math right now.) Are you asking for ntlm_mixalpha-numeric#1-9 or first letter mixalpha and then 8 more mixalpha-numeric or ntlm_loweralpha-numeric#1-9?

Comparing to the ophcrack set you mention they seem to have ntlm_loweralpha-numeric#1-9 as well. The sets we do not have but do have ntlm_loweralpha-numeric-space#1-8 (22GB) and ntlm_loweralpha-space#1-9 (50GB.)

Here is a topic regarding our not having ntlm_loweralpha-numeric#1-9: viewtopic.php?f=11&t=1446

EDIT: actually the conclusion of that thread is we can do ntlm_loweralpha-numeric#1-9 and it'll be faster to generate than ntlm_mixalpha-numeric#1-8 and for that matter smaller.

I'm asking for NTLM length 9 alphanumeric, with first letter capitalized. You're right of course, mixalpha_numeric_1-8 already exists here at FRT (and on my disks).

Just letting you know that the Ophcrack table set cracks passwords that are 8 characters long where the first letter (not just first character) is in uppercase.
So 8 characters long and matching this regex: [0-9]*([A-Z][0-9a-z]*|)
or well this regex: ([0-9]{8}|[0-9]{7}[A-Z]|[0-9]{6}[A-Z][0-9a-z]{1}|[0-9]{5}[A-Z][0-9a-z]{2}|[0-9]{4}[A-Z][0-9a-z]{3}|[0-9]{3}[A-Z][0-9a-z]{4}|[0-9]{2}[A-Z][0-9a-z]{5}|[0-9]{1}[A-Z][0-9a-z]{6}|[A-Z][0-9a-z]{7})
1234Asdf
Asdf1234
123Aa123
12345678

Not like this regex: [0-9A-Z][0-9a-z]{7}
1234asdf
Asdf1234
123aa123
12345678

So what I'm getting at is to reproduce this table set we can't just make a hybrid table like this:
*_hybrid(alpha-numeric#1-1,loweralpha-numeric#7-7)#0-0
or well not simply this since we have ntlm_mixalpha-numeric#1-8
*_hybrid(alpha-numeric#1-1,loweralpha-numeric#8-8)#0-0

But it doesn't matter too much. Ophcrack did it that way to prevent a lot of overlap with previous table sets. We could just do this then there is no overlap with older tables and it will be created faster as it has a smaller key space:
*_hybrid(alpha#1-1,loweralpha-numeric#8-8)#0-0

i remember awhile back you were saying there was an issue with the hybrid tables, is it fixed now?

I posted a patch for it but I don't know if it got added.

I believe the patch creates hybrid2 which has to be added to both distrrtgen and to rcracki_mt. It's not in rcracki_mt yet. It may have been incorporated into some code at gitorious (http://gitorious.org/freerainbowtables-applications)? A quick look at their logs indicate work on rti2 but no mention of hybrid2.

Sc00bz, could you make a speed comparison between the following sets ? (generation time and crack time)

md5_loweralpha#1-10_0_40000x6338500000
md5_loweralpha#1-10_1_40000x6338500000
md5_loweralpha#1-10_2_40000x6338500000
md5_loweralpha#1-10_3_40000x6338500000

and

md5_loweralpha#1-10_0_40000x5070700000
md5_loweralpha#1-10_1_40000x5070700000
md5_loweralpha#1-10_2_40000x5070700000
md5_loweralpha#1-10_3_40000x5070700000
md5_loweralpha#1-10_4_40000x5070700000

What about double md5 rainbow tables? - md5(md5($pass))

Some (not sure how many) offices/servers/sites use double md5 hashing instead of single md5 hashing.

also, double md5 rainbow tables can be gotten to work with single md5 hashes, by following a process similar to the one mentioned here - topic2045.html

I'm aware of a drawback though. Double md5 tables will take longer to generate and have longer cryptanlysis time versus single md5 tables.

Assuming the system runs again after we finish the md5_loweralpha set the double md5 suggestion isn't a bad idea. I'm not actually sure why we did mysqlsha1 aka double sha1 first as the applications of it are much fewer than double md5. Though, we probably need to first re-evaluate things like hybrid2 and rti2 as well as GPU support since we've hit some walls on length and charset for some hash algorithms.