<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Dec 21, 2013 at 11:46 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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="im">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><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><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. </div>
</div></div></div></blockquote><div><br></div><div>The biggest reason has been that web services can't expect clients to run something like scrypt in JavaScript. If it's e.g. a native application, there is no reason why you shouldn't offload this to the client.</div>
<div><br></div><div>There is some hope: PBKDF2 made it into the WebCrypto API spec, so you will at least be able to run e.g. PBKDF2-SHA256 in browsers as native code. There are also asm.js implementations of scrypt which seem reasonably fast.</div>
<div><br></div><div>As far as "simply replacing with scrypt" goes, I think it's unfortunate that most packages that implement it do so very confusingly, either with misleading terms such as "Password encryption", or solely as a KDF, with no instructions or API available to do something similar to bcrypt, which retains the parameter configuration in the digests it produces. The Password Hashing Competition (<a href="https://password-hashing.net/">https://password-hashing.net/</a>) will hopefully choose something with a simple API.</div>
<div><br></div><div>But yes -- you're singing my song, and probably that of many people on this list. It's a messy situation, and there's no good reason for it.</div><div><br></div><div>If the TrueCrypt authors were paid off to not implement something stronger, which I think is unlikely but can't reject is a possibility, there are other projects to support--FreeOTFE for example. But you're right that it seems awareness needs to be raised across the board.</div>
</div></div></div>