RE: [wss] Issue #282 - Pasword-based key derivation

["Hal Lockhart" <hlockhar@bea.com>]

Originally I was going to use PBKDF2 but as far as I can see the only benefit of its additional complexity is longer keys. But, as I argued in my posting, when you started with a password a user can remember, a key of 160 or even 128 bits more than captures the available entropy. I see little benefit and perhaps a false sense of security in using a longer one.

 

Hal

-----Original Message-----
From: Michael McIntosh [mailto:mikemci@us.ibm.com]
Sent: Monday, June 14, 2004 4:39 PM
To: Hal Lockhart
Cc: wss@lists.oasis-open.org
Subject: Re: [wss] Issue #282 - Pasword-based key derivation

"Hal Lockhart" <hlockhar@bea.com> wrote on 06/13/2004 10:30:53 PM:

> This has taken more research than I expected. Rather than delay further, I will
> post an overview of my approach, which may gererate some discussion. I will follow
> this with proposed text.
>
> Requirement
>
> Starting from a password typed by a user or some other value derived from it,
> generate a key suitable for use in an HMAC or symmetric encryption algorithm.
>
> Restrictions
>
> Both parties must share the same secret.
>
> The maximum key size generated under this scheme is 160 bits. Since a typical user
> password is the equivalent of only a 20-50 bit entropy source, this should not be
> an issue. (In other words, it makes no sense to use AES-256 when the key is derived
> from a password.)
>
> Approach
>
> This approach is based on (informational) RFC 2898, which is PKCS #5 v2.0.
>
> Two new elements are added to the Password Token: salt and iteration. These are
> sent along with the username, instead of the password. Signature and encryption
> elements can indicate the use of the derived key by means of a direct (local URI) reference.
>
> If key derivation is done, the salt must be present. The first octet of the salt
> contains hex 01 if the generated key is for an HMAC and hex 02 if the generated key
> is for encryption. All other values are reserved and MUST not be used. The next 120
> bits of the salt should be chosen at random.
>
> The iteration element is optional. If it is not present, its default value is 1000.
> If present a value of at least 1000 SHOULD be used.
>
> The key derivation scheme is based on the one called PBKDF1 in RFC 2898. SHA-1 is
> used as the underlying hash function. In brief the salt is concatenated to the
> password and repeatedly hashed the number of times given by the iteration value.
> The output will always be 160 bits. Low order bits are discarded to produce the
> required key length for encryption, e.g. 128 for AES, 112 for 3DES, etc. The full
> 160 bits are used for HMAC functions.
>
> Comments?

Why use PBKDF1 rather than PBKDF2?

"PBKDF1 is recommended only for compatibility with existing applications since the keys it produces may not be large enough for some applications."

"PBKDF2 is recommended for new applications."

>
> It would probably make sense to give the rationale for the key type, salt and
> iteration in the security considerations section.
>
> Hal
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS
> TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
>