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

[Tony Hansen <[e-mail]>]

On 2/24/15 6:56 AM, Stephen Farrell wrote:
> But in addition, there were two substantive issues that ought be
> resolved before IETF LC: ...
>
> 2. justify and possibly mandate an iteration count with which folks
>     are happy

The issue here is this text in draft-hansen-scram-sha256:

>     For the SCRAM-SHA-256/SCRAM-SHA-256-PLUS SASL mechanisms, servers
>     SHOULD announce a hash iteration-count of at least 4096.

Simon Josefsson's comment in saag was:

> A suggested (not even mandated) pbkdf iteration count of at least 4096
> is unchanged since RFC 5802 -- I'd really like to see that be
> significantly higher.  Back in 2000 an iteration count of 1000 was
> recommended as the minimum.  Surely computational power has increased
> more than a factor of four since then.

(Note: I think that recommendation of 1000 was for MD5, but let's assume 
SHA-1 in the following discourse.)

Alexey Melnikov responded:

> I've heard complains from developers that 4096 with SHA-1 is too high 
> for current Android phones. It would be good to get more information 
> on performance before changing the number.

to which Simon responded:

> You will always hear complaints from developers that security features
> adds computational and other resource costs.  When that happens, I
> prefer asking myself whether the threat model motivates the cost or not.

There is a balancing act with the minimum hash iteration count: 
usability versus security.

When this was last discussed in kitten last August, I brought the topic 
up myself, but I also noted that:

> I do know that we found 4096 iterations to be significant on a 
> handheld device, and I would *prefer* not raising it any higher. (We 
> would not be willing to change our existing implementation of 
> scram-sha-256 to a higher number unless there was a >>really good 
> reason<<.)

(This was specifically about 4096 iterations for SHA-256. SHA-1 runs 
better.)

A subsequent comment by Russ Allbery said:

> The rule of thumb that I was told by the CS crypto faculty at Stanford was
> to use a number of iterations such that string-to-key would take 0.1
> seconds on a computer with typical current performance.  That may or may
> not be practical, given...
>
>> I do know that we found 4096 iterations to be significant on a handheld
>> device, and I would*prefer*  not raising it any higher. (We would not be
>> willing to change our existing implementation of scram-sha-256 to a higher
>> number unless there was a >>really good reason<<.)
> ...you're already seeing performance issues with 4,096, and my testing
> showed that meeting that rule of thumb would require at least 14,500
> iterations of SHA-2 with PBKDF2.


So in 2000, the recommendation for SHA-1 was 1000. In 2010, the 
recommendation for SHA-1 was 4096 [RFC5082].

What is the definition for "typical current performance"? Should it be 
oriented toward mobile or oriented toward desktops or oriented toward 
super computers?

Does SHA-256 being slower than SHA-1 affect the answer any?

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.



Let the stones and arrows fly!

     Tony Hansen