[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]