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