Re: TLS shared keys PRF

[Hugo Krawczyk <hugo@xxxxxxxxxxxxxxxxx>]

On Sat, 10 Jan 2004, Eric Rescorla wrote:

> I just reviewed draft-ietf-tls-sharedkeys-02, and I'm not that
> comfortable with the use of the TLS PRF this way.The TLS PRF wasn't
> really intended for use as a key derivation function for textual
> keys. While it's probably secure in this mode, wouldn't it be better to
> use PKCS #5 (RFC 2898). I'd like to get assurance from some of the
> cryptographers before we proceed with this draft as-is.
>
> -Ekr
>

I took a look at draft-ietf-tls-sharedkeys-02 and at rfc 2898.
Indeed, as Eric says, the TLS PRF which requires a 48-byte random key
is not well suited for use with passwords. However, the truth is that NO
prf is really suited for that. All prf's are analyzed under the assumption
that the key is totally random and nothing can be implied for low-entropy
keys as those represented (or derived from) passwords. So any use of a prf
keyyed by a password (or by another key derived from the password) is
heuristic in nature.

What makes the TLS PRF even more "obviously inappropriate" for being keyed
with a password is that it requires a very long key (48 bytes) and,
moreover, it assumes that each half is indpendently random and
independent from the other half.

In any case I suggest the following mechanism for keying the prf in the
context of draft-ietf-tls-sharedkeys-02: Assuming that the keying material
derived from the password (i.e the shared secret) is no more than 24 bytes
then I would generate a 48-byte key for use with PRF as follows: the first
24 bytes (called S1 in the tls rfc) will be 0's, while the second half
(called S2) will be set to the shared secret. The effect of this is to
"reduce" the prf to HMAC-SHA1. The latter is consider edsufficiently
secure by any standards these days; the "safety margin" of xoring with md5
seemed more appropriate a few years ago. Today, we will be VERY surprised
to see cryptanalysis that applies to SHA1 and not to MD5 (even though this
is possible, in principle). BTW, note that this use of HMAC-SHA1 is almost
identical to that suggested in rfc 2868 (which adopted the key
derivation/expansion technique from tls and ike).

Two questions that can be raised here are:

Q: why concatenate with zeros BEFORE the actual key rather than AFTER?
A: Since TLS defines thast the first half keys HMAC-MD5 and the second
half HMAC-SHA1, and the latter is generally believed to be the strongest
function.

Q: Is the proposed mechanism better than, say, repeating the key twice?
A: I do not have an absolute answer here. What I can say is that from an
analytical point of view the mechansim I propose is secure if HMAC-SHA1 is
a secure prf, while the other option (repeated or related keys) may be
insecure even if BOTH HMAC-SHA1 and HMAC-MD5 are secure prf's (the only
way to prove the construction with related keys is to assume some strong
"computational independence between MD5 and SHA1).

Finally, regarding rfc 2868, it may be advisable to point to it in
draft-ietf-tls-sharedkeys-02 for ways to strengthen (at least to some
point) the derivation of "shared secret" from a password (in particular,
by including salt and other mechanisms  in the key derivation).
This could be specified as a SHOULD rather than a MUST given Peter's
intention to reduce to a minimum the implementation burden of this
spec.

Hugo


>