Free Rainbow Tables | Forum

Home of the Distributed Generator and Cracker
It is currently 06 May 2016, 07:26

All times are UTC + 1 hour [ DST ]

Post new topic Reply to topic  [ 2 posts ] 
Author Message
PostPosted: 03 May 2012, 07:30 
Perfect Table

Joined: 02 Apr 2008, 15:10
Posts: 944
Location: Bucharest, Romania
How much power of computation would I need in order to bruteforcefully search all the missing hashes-> plaintext from a md5_numeric#1-12 rainbow table ?

In other words the rainbow table success rate is 99.9 % (miss 1 in 1000), how much power of computation would I need to search each end every hash for the keySpace in order to get 100% and then store it in another lossless table ?

10^1 + 10^2 + ... + 10^12 = 1111111111110
1111111111110 / 1000 = 1111111111 = 2^30

A 2^30 keySpace is feasible. I think.

 Post subject:
Posted: 03 May 2012, 21:12 

PostPosted: 03 May 2012, 21:12 
MΩth √G∑∏∫∪≤

Joined: 03 Dec 2007, 11:37
Posts: 1061
Deja vu: viewtopic.php?p=11923#p11923

This explains how to do it:

Now that I've read the patent it's actually exactly what I wrote except that they used 256 files, bad file buffering, and they didn't do a full sort on the data just read the bit field file into ram and set the bits while reading the file with passwords. So it might be a little faster to copy the patent's way on the last point but doing a full sort using radix sort will mean you aren't violating the patent. When generating and storing the passwords if you store them in blocks of 2^20 passwords to save about 18 bits per password plus the savings of n bits from the initial bucket sort. Also storing it in a LHT* instead of storing the data as 2^n files (where the first n bits of the hash tells you the file number) with just a list of full passwords will help avoid patent issues and make it much faster and smaller.

* I said store it in a LHT even though they kind of are since they are not storing/indexing the full hash, but they store the full password so it's not a true LHT.


So cost is (chain count * chain length) links plus the cost of sorting that data (more than likely in several parts) and read and writing all that data to and from disk.


Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC + 1 hour [ DST ]

Who is online

Users browsing this forum: Exabot [Bot] and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group