<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 20, 2013 at 11:00 PM, Bill Cox <span dir="ltr"><<a href="mailto:waywardgeek@gmail.com" target="_blank">waywardgeek@gmail.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">SHA-XXX (all of them) seem to have been designed specifically to be cheap and fast to compute in custom hardware, while taking forever to compute on modern CPUs. </blockquote>




<div><br></div><div>An ASIC is always faster. It's only a problem if the algorithm is widely used and the public doesn't have access to hardware implementations. For something like AES, this isn't true.</div>

<div><br></div><div>The main principle behind password-based KDFs like scrypt is to make building ASICs to efficiently crack a digest database prohibitively expensive.</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">
Scrypt, used by FreeCoin, shows how to do truly effective key stretching,</blockquote><div><br></div><div>I'm really positively surprised to read this sentence. I would have never expected cryptocurrencies to be a reason people started talking about using expensive KDFs for something like password authentication.</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">I want a straight answer, and I truly don't know what it is.  Is it scary tall dudes in dark suits, or seriously ignorant devs?<br>




</blockquote><div><br></div><div>It's hard to believe there was a conspiracy. Too many people who have no relation to each other would have to be involved</div><div><br></div><div>It's much more likely that forcing an adversary to require more die area, and thus pay more for an ASIC to break something, is a plainly unsexy concept to most developers; that it's more of a failure of marketing than anything else. (That applies at the other end of the scale, too: Most professional cryptographers consider this a solved problem, so very few work on it.)</div>


<div><br></div><div>There are people who really should know better: IETF WG members, for example, who to this day submit drafts with password authentication mechanisms that amount to two iterations of SHA-256(salt+pwd.) That is inexcusable ignorance. But for the majority of developers, it's probably just that most don't know that there is a better way, and since there is no de facto library available to handle this stuff, they're forced to invent their own. (The closest to a standard has probably been bcrypt, which owes its success, at least in my opinion, to its extremely accessible API.)</div>


<div><br></div><div>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. Think about it: everything you do--database queries, template rendering, etc.--incurs overhead, so the solution isn't to make your password digest database weaker, but to prevent malicious users from doing those things over and over. (And if your application is really so big that *legitimate* logins are a DDoS concern, then you should be able to handle it without compromising user security by adding more hardware.)</div>


<div><br></div><div><div>Unfortunately, there are many programmers that share your attitude that crypto is way cool, but *don't* spend anywhere near enough time actually studying it before making the next big privacy-preserving social application with "military-grade AES 256-bit security." If they did, I think we'd see a lot more scrypt, bcrypt, PBKDF2, SRP, etc., and much fewer homegrown, ineffective contraptions.</div>

<div><br></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.</div>
</div>
</div></div></div>