<p>Not sure what his reply is going to be, but I can say that if there is a delay, it should be inherent to the method of key generation. For example, if using a strong password as input to a KDF that runs a million rounds, there will be a noticable delay to the key generation. Sadly, there is no way to pick a universally applicable number of rounds, though; very old systems won't be able to reasonably generate keys if there are more than several tens of thousands of iterations, while very new systems may not delay at all.</p>
<p>I have one system-in-progress that is setup to generate keys with 10,000,000 rounds, making the delay on my system around three seconds to generate the key. In the target environment it takes ~10 seconds. The only purpose is to reduce the feasibility of brute forcing by increasing the time it takes to generate a key.</p>
<p>It seems that 1,000 to 10,000 iterations is the common value, but on my systems this provides nearly no delay whatsoever. Certainly not one which is perceptable to me. Given a 3 second delay to generate a key that would mean that it my system can only brute 120 keys per minute, if those keys all pass through the algorithm. It also means that invalid passwords will take some time, even locally, to find that they are invalid, which is the point with something like this where there may not be a client/server interaction.</p>
<p>--<br>
Sent from my G2 running CyanogenMod!<br>
That is, a phone. :)</p>
<div class="gmail_quote">On Dec 23, 2010 6:34 PM, "Matty" <<a href="mailto:matty91@gmail.com">matty91@gmail.com</a>> wrote:<br type="attribution"></div>