[Cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement

[Bill Cox]

On 12/17/2013 4:58 PM, SafeChat.IM wrote:
> *
> Dear mailing list,
>
> A friend and me are working on a plugin that enables encryption on top 
> of Facebook messaging. The idea is to encrypt messages before they 
> leave the chat client, sending only the cipher to Facebook and decrypt 
> the message on the receiver client, before it is displayed. The plugin 
> automatically realizes which users have it installed and only encrypts 
> these chats.
> *

Very cool!

> *
> Since the reliability of the cryptographic system is a crucial part of 
> the design, I would to discuss the protocol here:
>
> First, we use PBKDF2 to derive a 256 bit data block from a passphrase 
> the user chooses and a salt (the username). We advise the user to use 
> a long and hard-to-guess passphrase. We use Parvez Anandam’s 
> JavaScript implementation [1].
> *
PBKDF2, just like TrueCrypt?  I hope you decide to have better password 
security than those guys.  The PBKDF2 key stretching in TrueCrypt is a 
joke.  You have to find an obscure option to even enable the 2000-round 
SHA256 key stretching, which provides close to no security at all.  The 
kinds of passwords your users on Facebook will actually use have very 
few bits of entropy, and can be guessed by hardware based brute force 
attacks very quickly.

To have much better password protection, take a look at the key 
stretching used in FreeCoin: scrypt.  While it is less effective at 
reducing hardware based password guessing attacks than it should be, 
it's still many thousands of times more effective than SHA-256 based key 
stretching.  I wrote some code that is like scrypt but it understands 
that we should thrash the on-chip cache while keeping the DRAM interface 
at 100% data transfer rates to more effectively beat hardware based 
password guessing.  Scrypt causes a cache miss every cycle, enabling 
hardware that does faster random access to accelerate it's key 
stretching by a factor of maybe 100.  Scrypt also has some undesirable 
properties such as needing to put scrypt parameters along side the salt, 
making it clear that the file is an script based encrypted password 
rather than random junk, reducing deniability.  My code gets around the 
weaknesses in scrypt that I perceived, but please just use scrypt rather 
than untested code. Freecoin proved scrypt works, and that's worth a 
lot.  Also, you guys will naturally do what everyone should be doing: 
perform the key stretching in the browser, not on the server.  For 
example, default Microsoft key stretching is only 1000 rounds of SHA-256 
because it's done in ASP.net on the server rather than in the browser.

Now for my tin hat conspiracy theories: Why is Microsoft so stupid about 
where to perform key stretching?  Why wont the TrueCrypt team adopt 
decent password security?  Why does PGP have 0 key stretching by 
default, and why is my SSH private key encrypted with no key stretching 
and no option to use it?  You want to encrypt Facebook traffic with real 
security?  I just have to wonder if some tall suits with dark sunglasses 
are going to convince you to do otherwise.  My other theory is people 
are really that stupid, whether they write SSH encryption code, PGP, or 
TrueCrypt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131218/ef066fcd/attachment.html>