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

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

>> don't think there are strong technical reasons to chose one over the
>> other at this point.  I used HMAC-SHA-256 for password-auth.
>
> Well, I think there are strong reasons to prefer SHA-256 over SHA-1: the
> existence of more attacks against SHA-1, the fact that SHA-1 will be
> considered obsolete in ~two years time.
>
> The main reason for preferring SHA-1 over SHA-256 is that
> implementations of the former are probably more widely available than of
> the latter.
>
> We can always specify multiple hash functions, make SHA-1 and SHA-256
> MUST implement and RECOMMEND SHA-256.  This means that implementors
> without suitable SHA-256 libraries will be "non-compliant" but their
> code will still be deployable, but at least we get a future-proof
> mechanism (for some values of "future-proofing").

One argument in favor of SHA-1 could be that SHA-1's total life-time in
service (1995-2010?) appears likely be longer than what SHA-256's total
life-time in service will be (2002-?).  I assume that once the SHA-3
competition is finished, that SHA-2 will be deprecated.

The total life-time in service corresponds to the amount of security
critical purposes the hash is used for.  Which consequently corresponds
to the amount of time researchers spend on trying to attack it.  That is
the best measure on a cryptographic algorithm's quality that we can use
in the IETF, I think.

On the other hand, this assumes that one year of cryptographic research
time in 1995 is worth as much as one year of cryptographic research time
in 2008, which isn't true.

I don't think we should specify both, it will cause interop problems.

I would be fine with HMAC-SHA-256.  It will take at least one year until
this RFC is published (if we are optimistic) and then it is even more
likely that all relevant platforms will have SHA-256.

/Simon