md5_mixalpha-numeric-symbol32#1-7

md5_mixalpha-numeric#1-8

would be verry nice

md5_mixalpha-numeric-symbol32-space#1-7

charSetLen = 95
keySpace = 70576641626495 = 2^46 //doable...but huge.



md5_mixalpha-numeric-space#1-8

charSetLen = 63
keySpace = 252158292852480 = 2^47.84 //huge



bfpoint : the "5000" rainbow tables are 2x slower than the "10000".

yes md5_mixalpha-numeric-symbol32-space#1-7 is huge but
I think also md5_mixalpha-numeric-symbol32-space#1-7 is a good idea

It seemed that we were going to generate some mysqlsha1 (aka double sha1) for a bit when we started doing the algorithm. Though, I don't know of much that uses double sha1 (http://hashkiller.com/index.php?topic=986.0). I'm actually more interested in sha1 (unsalted passwords in LDAP dbs for auditing purposes.) Though, we already have sha1_loweralpha-numeric-space#1-8.

We know md5 is widely used and am interested in if double sha1 has much utility outside mysqlsha1.

It also seems that generating some smaller tables before starting another huge set is a good idea. As we keep the site, and generation, more reliable/stable then we can attract more client cpu and then move on to larger sets. Also, the large md5 set is also going to be a lower set for lookups and md5 reversing and brute forcing are becoming more common place that the set may make less sense to generate.

It seems another thread has opened: viewtopic.php?f=11&t=2043

I'll add more over there.

Er, I'll continue in this thread.

32gb usb sticks are cheap and 64gb are getting cheaper. (http://www.pricewatch.com/flash_card_memory/) Given that and the sizes of the lm sets:
46G - lm_all-space#1-7
1.8G - lm_alpha-numeric#1-7

I don't see much reason to reinvent the wheel for those sets. Also, as windows Vista and 7 increase in use then the utility of LM will decline. In any case I don't think we should aim a set for a 4.7GB DVD when 8.5 GB are plentiful. Generating some smaller tables to carry around may also start to become more feasible for larger sets when blu-ray players become more common and the media becomes cheaper.

Also, don't forget that while larger the 2.5" usb external drives that don't require power are easy to toss in your bag and can hold a lot more.

Continuing previous thoughts on md5 v mysqlsha1 v sha1...

MD5 allows more reversing as per http://blog.distracted.nl/ than sha1. sha1 in general is slower period and in theory more migration to sha1 over md5 should occur as time passes. We have a very limited set of sha1 tables. As others have pointed out with mysqlsha1, I can just take an extra step of sha1(hash) and run that result in the tables.

_haxxor_ what about some configs for mysqlsha1/sha1?

summary: why not more mysqlsha1 for now and larger md5 later (which may become increasingly less relevant with hash reversing steps and so on.)

agree on the idea, i also suggest mysqlsha1 for now.
i'll be back with some configs.

mysqlsha1_loweralpha-numeric-space#1-8

loweralpha-numeric-space = [abcdefghijklmnopqrstuvwxyz0123456789 ]
charSetLen = 37
chainLen = 12000
numTables = 5
keySpace = 3,610,048,327,640 = 2 ^ 41.72
bruteForcePoint = 10,027

tableWorkFactor = 4.4886
chainLen = 1360000000 //ignore this
expectedUniqueChains = 420000000 //this is what we will do ;420 milion chains / table
tableSuccessRate = 0.752460326481245 = 75.246 %
tableSetSuccessRate = 0.999070554200416 = 99.907 % //perfected tables
totalUniqueChains = 2100000000

RTIv1 size = 19829673130 bytes = 18.467 GiB

some thought on this :
this config i gave is only 3 GiB smaller than this one.
and it's ~2 times slower. should we do the 4 table set, what sc00bz posted ?

the above bfpoint = 10,000
the md5 table bfpoint = 18,052

above RTIv1 size = 18.5 GiB
the md5 RTIv1 size = 21.8 GiB

above totalSuccessRate = 99.907 % (1 in 1075)
the md5 set totalSuccessRate = 99.9299% (Miss 1 in 1426)

should i try a config for a 4 table set ?

Sc00bz, any thoughts ?

Since there is so much computing power I think we should go with 4 tables per RT set as that will generate a RT set with a better time-memory trade off. You really only need to go to 5 tables per RT set if it will take "too long" to generate 4 tables per RT set. Total work factors are 22.443x for 5 tables per RT set and 51.132x for 4 tables per RT set. So 2.28 times more work for 4 tables per RT set. We are talking about a difference in days so it's not that bad. If it's a difference in weeks or months then you probably want to do 5 tables per RT set.

For those of you that want more stats on different table sets I wrote a post a while ago and it got put in "Important news and general Questions." Which was a great idea to create as it would have taken me a while to find my post.
viewtopic.php?p=10969&f=2#p10969

scoobz, could you create a " bigger " spreadsheet for this ?

could you include more digits ? like 12 or more ? and up to 100 tables/set. i'm very interested. (it may sound useless to know that many digits, but please)

btw could you extend it to 99.99% ? and down to 96.8 % ? thx !

ok, new configuration :

mysqlsha1_loweralpha-numeric-space#1-8

loweralpha-numeric-space = [abcdefghijklmnopqrstuvwxyz0123456789 ]
charSetLen = 37
chainLen = 10000
numTables = 4
keySpace = 3610048327640 = 2 ^ 41.72
bruteForcePoint = 18048

tableWorkFactor = 12.783
expectedUniqueChains = 624,328,590 ~= 625 milion perfect chains //this is what will are doing

mysqlsha1_loweralpha-numeric-space#1-8_0_10000
mysqlsha1_loweralpha-numeric-space#1-8_1_10000
mysqlsha1_loweralpha-numeric-space#1-8_2_10000
mysqlsha1_loweralpha-numeric-space#1-8_3_10000

every table has 625 milion perfect chains.

tableSetSize = 20.883 GiB ^_^

Wouldn't such a small set take almost no time with the current computing power? I I thought of an LM-table that would fit on an 8 GB stick and still leave some breathing room for BT4 (which needs about ~ 4GB). At least it would be a nice gimmick/giveaway, a BT/FRT-USB stick. I'll try and see how the lm_alpha-numeric#1-7 behaves when loading OS and tables from the stick.

what bruteforcepoint would be acceptable for a 7 GiB rainbow table set ? smth like 20 min of cracking time on a normal computer. (1 hash )

@ Schnitzelwecken BT4= backtrack 4 ?
uhm...then a LM rainbow table that's only ~4GiB ?

err... i tried to generate the best configs for lm_loweralpha-numeric#1-7 and realized that a bfpoint of 40000 is nice. i'll try to fit a loweralpha_numeric-symbol32 set in 6 GiB and see what bfpoint will emerge.

lm_alpha-numeric#1-7

loweralpha-numeric-space = [abcdefghijklmnopqrstuvwxyz0123456789]
charSetLen = 36
keySpace = 80603140212

RTIv1 size = 4 GiB = 4294967296 =>
4 tables : totalExpectedUniqueChains = 530106423 => expUCh = 132526606 => chainCount (tableWorkFactor = 12.783) = 979570409 => chainLen = 1051 => bFpoint = 40261
5 tables : totalExpectedUniqueChains = 528415301 => expUCh = 105683061 => chainCount (tableWorkFactor = 4.4886) = 342867555 => chainLen = 1055 => bFpoint = 32209
6 tables : totalExpectedUniqueChains = 526724179 => expUCh = 87787364 => chainCount (tableWorkFactor = 2.7222) = 207274746 => chainLen = 1059 => bFpoint = 26840

so, we need to create 4 tables for the best rainbow table set.
bfpoint ~= 40300
numTables = 4
chainLen = 1000
RTIv1 size = 4GiB.

LE: erm...uuups, the table set is already smaller than 4GiB (1.76 GiB)
ignore all the above.

wild idea : let's create a 3 table set, with the maximum success rate : 99.75202349% (1 in 403)

what would be the tableWorkFactor, Sc00bz ? why did you wrote there N/A ???


(for lm_all-space#1-7)
LE: if you can't calculate the workfactor for 99.75202349 (1:403), then what is it for (1 in 256) 99.609375 % ? or smth in between.

i'm asking this, because i think we could fit lm_all-space#1-7 in 4-6 GiB, given the big tableWorkFactor. (the current table set is over 44 GiB)

4th post

@Schnitzelwecken 32 GB stick is smth very convenient.
i'll try to fit all-space on 12 GiB (16 GiB stick), and on 28 GiB (32 GiB stick)

LE1 :
here's a configuration for a 16 GiB stick ( ~12 GiB rainbow table set )
lm_all-space#1-7

chainLen = 54000
bFpoint = 1295
expectedUniqueChains = 244000000
chainCount = 1803526000
totalexpUCh = 976000000

tableSuccessRate = 0.82515241069698028 = 82.515 %
tableSetSuccessRate = 0.9990653724134616942 = 99.906 % (1 in 1070)

RTIv1 size = 12880903044 = 11 GiB 1020 MiB 190 KiB 900 B

lm_all-space#1-7_0_54000x244000000
lm_all-space#1-7_1_54000x244000000
lm_all-space#1-7_2_54000x244000000
lm_all-space#1-7_3_54000x244000000
//each table has 244 million perfect chains.