OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


PBKDF1 also introduces a pseudo-random (or for that matter hardware generated random) salt for this purpose. Based on the contents of RFC 2898 and materials available from RSA, I believe these methods are equivalent in cryptographic strength. The difference is the restriction on key length.

Hal

> -----Original Message-----
> From: Michael McIntosh [mailto:mikemci@us.ibm.com]
> Sent: Thursday, June 24, 2004 6:15 PM
> To: Hal Lockhart
> Cc: wss@lists.oasis-open.org
> Subject: RE: [wss] Issue #282 - Pasword-based key derivation
> 
> 
> 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.
> > 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]