Re: Improving password hashing

[Colin Percival <cp...@tarsnap.com>]

[Replying via the list archives; sorry for breaking In-Reply-To: threading.
Please CC me on replies.]

Robert Newson wrote:
> Because PBKDF2 has been designed and tested by cryptographers

I'm a cryptographer, and I designed and tested scrypt.

> and is fully described in RFC 2898

I fully described scrypt in my paper.

> which includes test vectors to verify an implementation.

I provided test vectors in my paper.

> bcrypt is tied to a now obsolete cipher (blowfish),

Agreed.  bcrypt is slightly more secure than PBKDF2, but not enough to
justify bringing in extra code.

> I don't know anything much about scrypt but anyone can claim they
> designed it to be more secure, but proving it is another matter.

The scrypt paper contains a proof of security for a simplified version; that's
much more than any other KDF has.

There are good reasons why you might want to use PBKDF2:
1. Standards-compliance.
2. Not wanting to import a large amount of new code (scrypt is considerably
more complex than PBKDF2).
3. Trading security for low memory footprint (scrypt is secure because it's
impossible to compute it quickly without using lots of RAM).
but the reasons you've given aren't among them. ;-)

If you do decide to use PBKDF2, I'd recommend PBKDF2-SHA256 rather than the
standard PBKDF2-SHA1; there's no security advantage, but SHA1 is deprecated
generally and you don't want to have someone discover grep in 2015 and send
nasty emails saying "hey, you're using a broken hash!"

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid

Re: Improving password hashing

[Robert Newson <rn...@apache.org>]

Thanks Colin. I did note that I knew little about scrypt, I appreciate
the details.

Agree about sha-1, of course, the main reason the code doesn't use
sha-256 is that it's not currently available in the Erlang OTP
platform. Even when it is, it will be a while before we can move the
lower bound of our platform requirement to insist on it. Fortunately,
its simple matter to test for the presence of sha-256 (once it lands
at all, perhaps in R15) and use it, but fallback to sha-1 if not.

All of these options improve on the current situation.

B.

On 8 July 2011 05:10, Colin Percival <cp...@tarsnap.com> wrote:
> [Replying via the list archives; sorry for breaking In-Reply-To: threading.
> Please CC me on replies.]
>
> Robert Newson wrote:
>> Because PBKDF2 has been designed and tested by cryptographers
>
> I'm a cryptographer, and I designed and tested scrypt.
>
>> and is fully described in RFC 2898
>
> I fully described scrypt in my paper.
>
>> which includes test vectors to verify an implementation.
>
> I provided test vectors in my paper.
>
>> bcrypt is tied to a now obsolete cipher (blowfish),
>
> Agreed.  bcrypt is slightly more secure than PBKDF2, but not enough to
> justify bringing in extra code.
>
>> I don't know anything much about scrypt but anyone can claim they
>> designed it to be more secure, but proving it is another matter.
>
> The scrypt paper contains a proof of security for a simplified version; that's
> much more than any other KDF has.
>
> There are good reasons why you might want to use PBKDF2:
> 1. Standards-compliance.
> 2. Not wanting to import a large amount of new code (scrypt is considerably
> more complex than PBKDF2).
> 3. Trading security for low memory footprint (scrypt is secure because it's
> impossible to compute it quickly without using lots of RAM).
> but the reasons you've given aren't among them. ;-)
>
> If you do decide to use PBKDF2, I'd recommend PBKDF2-SHA256 rather than the
> standard PBKDF2-SHA1; there's no security advantage, but SHA1 is deprecated
> generally and you don't want to have someone discover grep in 2015 and send
> nasty emails saying "hey, you're using a broken hash!"
>
> --
> Colin Percival
> Security Officer, FreeBSD | freebsd.org | The power to serve
> Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
>