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" <> 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:]
> Sent: Monday, June 14, 2004 4:39 PM
> To: Hal Lockhart
> Cc:
> Subject: Re: [wss] Issue #282 - Pasword-based key derivation
>
> "Hal Lockhart" <> 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.
> >
