Re: my KDF vs dictionary attacks

Antony Clements wrote:
"David Eather" <eather@xxxxxxxxxx> wrote in message news:13u97io912p7l58@xxxxxxxxxxxxxxxxxxxxx
please read these entries in wikipedia:

http://en.wikipedia.org/wiki/Key_derivation_function
http://en.wikipedia.org/wiki/Key_strengthening

To anyone else: Seriously I want some feedback, was what I posted to difficult / confused / obscure etc. to be useful? Yes my email address if you prefer.

insert sigh here<

David, i am using a hash to stretch the key already, I have been for a while, sha512 in fact

Terminology might be catching you here. Using the hash function rather than applying the password as a key directly is a good move. "Stretching" has a meaning of making the password to key function take more time.

All it takes for an attacker to figure out the whole key structure is as follows

assume for a second 2 pass phrases and 1 salt to make things easier on the brain

the attacker takes those hashes and then mixes the output of the sbox with a hex byte providing a byte for the actual key that is used, repeat for however many hex bytes there are

there are 2^512 possabilities, hash each of those possabilities with the last output of the sbox and you have the hash basis of the next block key, since the sbox is completely linear it will only ever take 2^512 guesses at an absolute maximum for an attacker to guess the first useable key for the _first block_

yes.



with only 2^50.828919980758942629441372102717 possible key+salt combinations it's almost trivial to find the base hash for the _first block_

Not trivial, but certainly possible. This is what password stretching helps with. Because the password to key function now takes time to compute a smaller number of possibilities may be sufficient the reason is that it takes more time to find the key and with a little bit of luck or design that can be pushed into the realms of infeasible for the attacker.

the entire KDF is based on modifying a hash output in a pseudo-random way such that

keybyte == hexbyte xor n mod 256, where n is the output of the sbox

the problem with the KDF, as i mentioned before, is the linear sbox, in that once the original salt is known, every single output of the sbox is also known thereby still only requiring 2^512 attempts to find the correct hash etc

2^512 is a massive number. Having a known s-box is not a problem almost all cypto algorithms have known s-boxes (also linear is a crypto term with a specific meaning. Most s-boxes are reasonably non-linear )

taken from wikipedia

key = hash( password + salt )
for 1 to 65000 do
key = hash( key + salt )

now my code

key = hash( password + salt )
for 1 to n do
f(key)
key = hash( key + salt )

the ONLY difference between the pseudo-code on wikipedia and my code is that i am not iterating 65000 times per block, i am iterating once per block, the reason why i am only iterating once per block is because in a brute force attack it makes no difference how many iterations there are,

I am assuming you are using the hash function to assemble a stream cipher. The number of iterations does make a difference for the starting point. No one can search the entire 2^512 outputs that are possible, so they will attack by trying to find the password - making the initial password to key transform slow makes the attacker's work more difficult. The wiki example for example adds the equivalent of 16 bits more to the key because of the time it takes.

as there is
only ever 2^512 possible combinations in a 512-bit byte-stream that uses the full byte table rather than the 2^256 tries to guess a single hex stream

now can you please answer the question, would using every byte within the byte table increase the maximum size of the dictionary, and would having varying sizes of user keys also increase the dictionary size

it's almost a simple yes or no answer

There are other answers possible, for example I don't understand your question. I can't see any reason to do what I think you are suggesting. I don't know why you are thinking of a 200000 entry dictionary of pass-phrases, why you want one, or why you want to expand it. To compete with the wiki example you would want something like 13,107,200,000 entries.

i dont know why it is that almost everyone in this group either takes things out of context or just plain doesnt read the post properly


Because you don't explain yourself very well. You make basic errors and use faulty terminology (which wouldn't be a problem if you explained what you intended and why)

You are just SO LUCKY that JP no longer posts here.
.

Relevant Pages

  • Re: my KDF vs dictionary attacks
    ... assume for a second 2 pass phrases and 1 salt to make things easier on the ... hash each of those possabilities with the ... last output of the sbox and you have the hash basis of the next block key, ... i am not iterating 65000 times per block, i am iterating once per block, the ...
    (sci.crypt)
  • Re: Is this secure
    ... What I do in my business layer I get the salt, then I use my custom classes ... to hash the passed in password then send the Hash to a Stored Proc to ... Both the hashed password and salt are stored in the database. ... but then i'd need the salt to create a saltedhash to ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Can Kerberos be cracked??
    ... Subject: Can Kerberos be cracked?? ... A "salt" is a "random" value that is appended to the ... possible for you to dictionary-crack my password unless you know the ... >> In order to get the hash you would need to launch a brute force attack ...
    (Focus-Microsoft)
  • Re: Is this secure
    ... I use SHA1 to hash my passwords. ... Both the hashed password and salt are stored in the database. ... but then i'd need the salt to create a saltedhash to compare ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Is this secure
    ... I use SHA1 to hash my passwords. ... Both the hashed password and salt are stored in the database. ... but then i'd need the salt to create a saltedhash to compare ...
    (microsoft.public.dotnet.framework.aspnet)