Re: [http-auth] Proposed change for MutualAuth (1) - Use of Password-hardening

[Ilari Liusvaara <[e-mail]>]

On Thu, Mar 06, 2014 at 01:46:56AM +0900, Yutaka OIWA wrote:
> Following the discussion in the HTTPAUTH WG sessions in
> several previous meeting,
> I believe it is a good thing to introduce a password hardening
> into the current MutualAuth draft.

I actually had the same idea (but didn't post it to the list).

> In Section 11.2 (Default Functions for Algorithms),
> 
> ---OLD---
>    pi = INT(H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username)
>    | VS(ph(password)))).
> ---
> will be replaced with
> ---NEW---
>    pi = INT(PBKDF2(HMAC-H,
>                    ph(password),
>                    VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username),
>                    2048, dkLen))
> 
>    where
> 
>      o HMAC-H be the HMAC function [RFC2104] composed from the hash
> function H, and
>      o dkLen shall be the length of hash H, counted in octets.
> ---
> 
> The open issues for the above change are:
> 
>  * Which function, possibly other than PBKDF2, will be the best
>    choice for the hardened password hash function?
>    I currently chose PBKDF2 just because there is an RFC.

Basically, there are two kinds of "slow" password derivation:
- Ones that burns CPU.
- Ones that burn both CPU and memory.

The latter are meant as anti-GPU, as otherwise one can use GPUs for
high-performance password cracking.

Unfortunately, while using fair amount of memory previously made GPU
performance really fall off the cliff, that doesn't really happen anymore,
but it still limits paralelism on GPU nicely.

I think someone mentioned scrypt (or was it bcrypt)? Those both are
well-known memory-burning password stretching functions. I don't
think either has an RFC.

>  * What number of iterations are to be used?
>     Fixing it to 2048 makes sense?  Or it should be a security parameter?

As someone else said, 2048 for PBKDF2 is vastly insufficient (but for
some other algorithms, iterations may be vastly more expensive).

I would guess that the iteration counts for PBKDF2 nowadays would be in
hundreds of thoursands or even millions. But that's just guessing
(I have done some homebrew password stretching functions, those have
iteration counts in millions).

>  * What is the best value for dkLen?
>    It is an output length of the hardened password hash in octets.
> 
>    Hereafter assume SHA-256 hash and 2048-bit DL key exchange are used.
>    The above definition lead to the value 256/8 = 32.
>    It is easy to make it larger, up to 1792/8 = 224 (1792 = 2048 - 256).
>    The cryptographically best values are either 2046/8, or
>    more precisely some irrational number 2046.99999..../8 (*), but
>    to achieve it, we need to modify/update PBKDF2 itself.
>    (*) 2046.99999... is log_2 r, where r is a number of mathmatically
>    possible elements (size of the generated group) for the passwords-equivalent.

On the last point, if one wanted to hash to group order, the standard method
is to generate slightly larger number of bits (NIST says at least 64, I would
say at least 100), interpret the number as integer and then take modulo r.
(or modulo (r - 1) + 1)

This tends to be bit slow with larger groups, especially if the order is not
near-power-of-two (IIRC, NIST P-224, NIST P-521, all E-series and all M-series
elliptic curves do, NIST P-256 and P-384 don't).

I think there was some RFC that described how to use hash function to stretch
input...

I don't know if hashing to group order is needed or not. I know SRP does
not do it, it just takes 256 (or whatever) bit hash function value and uses
that as an exponent.


-Ilari