Re: Crypto agility in SCRAM + draft-josefsson-password-auth?

[Simon Josefsson <[e-mail]>]

Chris Newman <[e-mail]> writes:

> I am not convinced the security value of PBKDF-2 offsets the
> additional complexity it adds.  Remember there is negative security
> benefit if we use PBKDF-2 and the additional complexity pushes the
> mechanism over the edge into the "not worth implementing" category.
> It may be not a lot of complexity, but every bit matters.

Implementing PBKDF-2 is easy:

http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/gc-pbkdf2-sha1.c;hb=HEAD

You can find PBKDF-2 implemented in some crypto toolkits.  Using such
toolkits may reduce implementation complexity in some environments.

There are test vectors available for PBKDF-2 and also source code
examples.  Neither is available for the Hi(HMAC()) idea in SCRAM, as far
as I can tell.

> While I would personally be fine with abandoning MD5 in favor of SHA1
> given my code toolkit has both algorithms, I'm concerned about the
> impact. Everyone's code toolkit includes MD5, but use of SHA1 is quite
> rare in applications at the moment.  Switching away from MD5 will
> create a deployment barrier.  Again, it doesn't matter how much more
> secure SHA1 is than MD5 if the SHA1-based mechanism doesn't deploy and
> an MD5-based one might have deployed.  I'd like to hear from other
> SASL implementers before making a firm decision on this one: do you
> have SHA1 in your code toolkit? If not, how hard would it be to add it
> and would that be a deployment barrier?

In my experience, these days SHA-1 is as widely available as MD5.  Any
applications that implement TLS has a SHA-1 implementation somewhere.
Certainly my SASL library has no problem using SHA-1.

/Simon