<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Dec 21, 2013 at 6:07 PM, Patrick Mylund Nielsen <span dir="ltr"><<a href="mailto:cryptography@patrickmylund.com" target="_blank">cryptography@patrickmylund.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="im"><span style="color:rgb(34,34,34)">The most popular argument against something like scrypt seems to be that using an expensive function makes you susceptible to DDoS attacks. This is true, but it's also completely beside the point.</span><br>
</div></div></div></div></blockquote><div><br></div><div>I don't understand why servers do the KDF rather than the client.  The current system requires that the password be transmitted to the server, and users have to trust the service provider to be honest.  This provides a couple ways for attackers to compromise the password.  Just pay off the guys running the server ($10M anyone?), issue them a court order of some sort, or override the CA and do the man-in-the-middle thing.  As soon as you transmit your password to the server, security is already broken.</div>
<div><br></div><div>With client-side KDF, the DDoS issue goes away, the servers have a far lighter load, and users get real password security.  Why is the current flawed system used?  I just don't understand it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><div>Similarly, the people who do know better owe it to the average consumer to be advocates for things like KDFs in password authentication constructions, even if they are old and unsexy concepts.<br></div>
</div>
</div></div></div>
</blockquote></div><br></div><div class="gmail_extra">The guys in charge of mainstream crypto algorithms don't seem to be doing KDFs very well.  It's not just the lame server-side KDFs.  The one that really bothers me is TrueCrypt, which in user-land is more popular than all the rest combined by a factor of several.  About 90% of all file encryption in user-land (not corporate or server side) is done in TrueCrypt.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I've scanned through the code, and the strongest KDF you can select is 2000 rounds of AES-512.  By default it uses something far weaker.  From BitCoin, we learned that custom hardware can deliver SHA-256 hashing at a rate of 1 giga-hash/second for $10.  If you have on the order of $1B to spend, you can do 10^17 SHA-256 hashes per second or 10^16 SHA-512 hashes.  A $1B machine could do close to 10^13 KDFs/second of TrueCrypt's strongest KDF.  Given that the NSA only claims to be able to do something like 1T password guesses/second, TrueCrypt's max KDF seems to provide little additional security, at least against custom hardware guessing machines.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">In addition to a weak KDF, users are encouraged to use weak passwords.  For example, <a href="https://howsecureismypassword.net/">https://howsecureismypassword.net/</a> says that "dogs breakfast" would take a desktop PC a million years to crack.  My Huffman Code password compressor represents this pass phrase as 011011101110010 1110111101011110 - 31 bits.  My password cracker on a PC would guess this password in about 2 billion attempts, or about 70 years if each guess required a full second of KDF  With the weak TrueCrypt KDF (about 50 milliseconds on a PC), that drops to 3.5 years.  With a graphics card, that drops to days, not years.  At 1T password guesses per second, this password would be cracked in 2 milliseconds!</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">A $1,000 PC might do 50,000 SHA-512 hashes/second, while for $20, I can do 1e9 AES-512 hashes/second with an ASIC.  Why give attackers a free factor of a million advantage for using custom hardware?  Why do we even quote password strength in terms of how long a PC would tack to crack it?  Simply switching to scrypt reduces the cost advantage of custom hardware from a million to maybe 100.  Done right, we could reduce it to 10 or less.  I just don't understand how these guys can live with weak key stretching.  At a minimum, they should let users select the number of iterations for the SHA-512 KDF.  GPG at least does that.  I'm suspicious there may be some cash being paid to the right people to make sure TrueCrypt key stretching stays weak.  If RSA got $10M, what did the TrueCrypt guys get?  Simply adding an option for user-selectable rounds of key stretching would take about 10 minutes of coding.</div>
</div>