Re: [kitten] draft-hansen-scram-sha256 and the hash iteration count

[Simon Josefsson <[e-mail]>]

Tony Hansen <[e-mail]> writes:

> So, what to do for SCRAM-SHA-256?
>
> One way to derive a recommended number might be to use a log scale
> between 2000's and 2010's numbers, extend it out to 2015, then reduce
> the number by some percentage to account for SHA-1 vs SHA-256
> performance. If my math is correct, and using a performance reduction
> of 30%, this gives 4260, which is only a few percent away from my
> original recommendation of 4096 for SHA-2.
>
> Or we could jump all the way up to 14500, as suggested by Russ.
>
>
> Another possibility is to suggest two values: one for mobile use and
> one for non-mobile use.

I think there are at least two different considerations:

1) Language used.  As you quoted, the text now says that servers "SHOULD
announce at least 4096".  Using SHOULD already gives room for using
other values if there is good justification.  To split things into
mobile and non-mobile use-cases (which sounds like a bad idea for
several reasons to me) would require changing the language, as the
server normally doesn't know what type the client is.  Another idea is
to give two values but phrase it in a different way: one MUST minimum
value for protocol conformance (say 4096) and one RECOMMENDED value for
good protection in various deployments (say 14500).

2) How to decide the value.  I don't agree with the focus on performance
-- the reason for using PBKDF2 is to improve security, so the normal
approach to decide security parameters (compare key sizes) is that the
security needs dictate the requirements.  On one extreme, using 10
iteration count would be weak (although I can't cite attacks, maybe
because nobody uses 10 iterations...).  IMHO, the metric should be: how
many iterations raises the cost for an attacker so that it is no longer
a cost-effective way to crack the system?  Of course, different systems
will have different attack cost models, but we should give a ball-park
number applicable for common Internet applications.  I'm with Alexey
that current estimates are probably mostly guesses.  I don't know of a
established way to derive a better value.  However it feels weird for us
to not raise the value when we are revising the specification: surely
all attacks are more cost-effective as time passes by, so the value
should at least be incremented somewhat.

/Simon