jarrod0987 wrote:
"Yes but they are sorted or indexed on the hash so you can search for the hash. With WPA-PSK order doesn't matter because you have to test each entry. Although you would want the most likely password first."
So what your saying is, Rainbow tables are for when you have a hash to look up. With WPA-PSK you have no hash to look up so you have to try every possible combination? Sorting just increases your likelyhood of finding it faster?
Yes and yes.
jarrod0987 wrote:
I thought you would use monitor mode to capture a hash of the PSK or perhaps just some random comunication and then use the rainbow table on your recorded sample? Is that not correct?
You can't because it is "salted" per every connect. Basically you capture encrypted data of with a key that is a hash of the two MACs, two nonces (number used once), and the PSK. Given the 256 bit PSK you have access to the network so there is nothing to crack.
jarrod0987 wrote:
"You lookup 3708 and then you find that chain "3 - 3708".
3708 is the endpoint, I found it in the table and it gave me the magic number of 3. Yes?
yes
jarrod0987 wrote:
" Then you do H(R2(H(R1(H(3))))) = H(45) = 3708."
So we run it through R1 and R2 and we get 3708 which is what we should get if our table is working right. Yes?
3 is a password so you hash it then run it through R1 then hash it again and then R2 and then hash it again.
jarrod0987 wrote:
" You have to search for hash, H(R2(hash)), and H(R2(H(R1(hash)))) which you will need to do H(R2(H(R1(H(start point))))), H(R2(H(start point))), and H(start point) respectively."
This is where I'm loosing it. What am i still searching for? I already figured out 45 is my Plain text of the hash 3708? Isn't that what I wanted to know?
"hash" is what ever hash you are looking for. This is the general case for when you don't find it or haven't found it yet. Once it's found you stop.
jarrod0987 wrote:
To make sure I understand how your refwering to things.. H(R2)hash)) = Hash of R2 which was the first 2 numbers of the hash we did just before it?
It's H(R2(hash)) which is do R2 of "hash" (ie 3708) then hash that.
jarrod0987 wrote:
"H(R2(H(R1(H(start point)))))" Isn't this just a mathamatical way of saying we take the 6 and recreate the chain using our hash and reduction functions?
In this case yes, but usually chains end in a reduction function like "R3(H(R2(H(R1(H(start point))))))" and then you would need to run through "H(R2(H(R1(H(start point)))))".
jarrod0987 wrote:
Perhaps you could run me through an example so I can see what is happening.
1 So I have 3708 as a hash from something I am trying to get the plaintext for.
2 I look up 3708 in my rainbow table and I find it. = 3 3708
3 I hash the 3. = 3955
4 I check to see if 3955 is 3708. Nope.
5 I take the R1 of 3955. = 55.
6 I hash55. = 4532
7 I check to see if 4532 is 3708. Nope.
8 I take the R2 of 1977. = 45
9 I hash 45. = 3708
10 I cehck to see if 3708 is 3708. Yes.
11 45 is the plain text of 3708. This is the "Decoded" hash I was looking for.
Is anything here not proper?
Step 4 and 7 are not done because you know that a possible password is going to be the 3rd password in the chain.
When searching a rainbow table you assume that the hash you are looking for is in each of the columns then you finish the chain and then look up that endpoint in the rainbow table. If you find the endpoint in the table then you need to reconstruct the beginning of the chain up until the password before the column the hash was assumed to be in. Then you hash the password and see if it matches the hash. If it matches then you found the password otherwise it was a false alarm.
Also note that each column is a password and it's hash. It's so that chain length is the same as number of columns although this gets messed up a little when chains end in a reduction function. Some formulas use chain length as the number of hashes in the chain and in other formulas chain length is number of passwords in the chain.