GRT Table Version 3?
Posted: Fri Jun 01, 2012 8:25 pmWhen did this happen? I'm guessing it's still in beta.
From the code it looks like you are still doing random start points and storing the seed so you can recover the start points from the random number generator. Just letting you know that sequential start points are better as you don't get duplicate chains and it's easier to do plus 1 than generate random numbers with Mersenne-Twist. Also "random start points give you better coverage" is a myth the only difference is you get to choose the first password in the chain verse not knowing the first password until you've run it, and if you count the fact that you get duplicate chains with random start points then it's actually worse coverage.
If you are still going to do a random number generator then do something like md5(cat(seed, index)). Which if you think about it only increases the the cost to generate by 0.001% with a chain length of 100,000. That's about how much it slows down for moving the mouse. That way you don't need to sort the found chains by the start point then generate O(passwordLength*chainCount) = O(passwordLength*N^(2/3)) random numbers (or worse generate O(passwordLength*chainCount*chainLength) = O(passwordLength*N^(2/3)*N^(1/3)) = O(passwordLength*N) random numbers).
I would argue that something like md5(cat(seed, index)) give you a better random start points than Mersenne-Twist, but I'd also argue that something like md5(cat(seed, index)) is equivalent to sequential start points after they are hashed.
GRTGen-CUDA.exe -h MD5 -c charsets\charsetall -l 7 -i 0 --chainlength 100 --numchains 10000 --tableversion 3
Cryptohaze GRTGen 1.00
WARNING: Chain length of 100 seems out of a normal range.
GRTGenerateTable: Hash: 16 Pass: 16
Table generation information:
Hash type: MD5
Password length: 7
Table index: 0
Number of chains: 10000
Number of tables: 1
Chain length: 100
Generate seed: 1103988403
Charset filename: charsets\charsetall
Creating table 1 of 1
Creating GRTV3 output table.
Random seed: 1103988403
Output to: parts/MD5-len7-idx0-chr95-cl100-sd1103988403-0-v3.part
Table version: 3
Hash: MD5
Password length: 7
Table index: 0
Chain length: 100
Num chains: 10000
Perfect table: No
Charset length: 95
Charset: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQR
STUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
Bits of hash: 96
Bits of pass: 0
Generate seed: 1103988403
Chain start offset: 0
Charset length: 95
Kernel Time: 3.700 ms Step rate: 270.28 M/s Done: 0.00%
From the code it looks like you are still doing random start points and storing the seed so you can recover the start points from the random number generator. Just letting you know that sequential start points are better as you don't get duplicate chains and it's easier to do plus 1 than generate random numbers with Mersenne-Twist. Also "random start points give you better coverage" is a myth the only difference is you get to choose the first password in the chain verse not knowing the first password until you've run it, and if you count the fact that you get duplicate chains with random start points then it's actually worse coverage.
If you are still going to do a random number generator then do something like md5(cat(seed, index)). Which if you think about it only increases the the cost to generate by 0.001% with a chain length of 100,000. That's about how much it slows down for moving the mouse. That way you don't need to sort the found chains by the start point then generate O(passwordLength*chainCount) = O(passwordLength*N^(2/3)) random numbers (or worse generate O(passwordLength*chainCount*chainLength) = O(passwordLength*N^(2/3)*N^(1/3)) = O(passwordLength*N) random numbers).
I would argue that something like md5(cat(seed, index)) give you a better random start points than Mersenne-Twist, but I'd also argue that something like md5(cat(seed, index)) is equivalent to sequential start points after they are hashed.