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

[Michael McIntosh <mikemci@us.ibm.com>]

Hal,

My impression was that PBKDF2 was more secure because it introduced the 
use of a psuedo-random value in order to reduce the threat from dictionary 
attacks.

thanks,
Mike

"Hal Lockhart" <hlockhar@bea.com> wrote on 06/15/2004 09:10:19 AM:

> 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.
> >