Subject: [Cfrg] Extractor for use with PAKE protocols (specifically J-PAKE) / unauthenticated nonces

From: Brian Smith <[email-masked]>
Date: Wed, 3 Nov 2010 12:07:37 -0700 (PDT)

In the J-PAKE paper [1], the authors suggest simply using using a hash function as an extractor following Diffie-Hellman key exchange. (The sample implementation [2] uses SHA-1 and the authors subsequently suggested using SHA-2.) My investigation of extractors has lead me to believe that it much better to use an extractor that is seeded/keyed by an authenticated nonce. But, in J-PAKE, we can authenticate the key exchange but we can't directly authenticate the nonce.

I saw Hugo Krawczyk's response in the thread "CMAC for Extraction" [3] that said "If your protocol cannot exchange a nonce, or can exchange it but cannot authenticate it (in which case the nonce can be chosen by an attacker) then replace N with a fixed value that is defined and wired it into the protocol as a constant. Choose N to be any 'random' string of the length of a CMAC key." But, it isn't clear to me how to evaluate the security of this. 

In TLS, with static-static (EC)DH key exchange, nonces do not seem to be authenticated except indirectly through the client finished message. Would copying that design be better or worse than using a fixed N value instead of a nonce?

Thanks,
Brian Smith

[1] http://eprint.iacr.org/2010/190
[2] http://www.lightbluetouchpaper.org/2008/05/29/j-pake/ (see the updates section)
[3] http://www.ietf.org/mail-archive/web/cfrg/current/msg02880.html

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 3 Nov 2010 12:55:10 -0700 (PDT)

Hi Brian,

  In EAP-pwd (RFC 5931) we used HMAC-SHA256 as an extractor (to concentrate
the results of the key exchange) and keyed it with 32 octets of zero. This
serves the purpose of EAP-pwd -- that of a random function-- and it would
probably serve your purposes as well.

  I do not want to be perceived as putting words into Hugo Krawczyk's
mouth but I believe you are misinterpreting the use of salt in an
extractor function. If you are able to exchange nonces and combine them,
so that each side chooses one, into a salt for an extractor I do not
believe that the nonces have to have proof of origin assigned to them--
some kind of "authentication"-- prior to using as a salt to an extractor.
The nonces can be used as salt with the derived D-H secret as the data
and that can be passed to the extractor to create a key from which a key
confirmation key can be derived which can be used to authenticate the
exchange.

  In my opinion using the nonces in the exchange would be better than a
constant value. If you can exchange nonces, the use them!

  Dan.

On Wed, November 3, 2010 12:07 pm, Brian Smith wrote:
> In the J-PAKE paper [1], the authors suggest simply using using a hash
> function as an extractor following Diffie-Hellman key exchange. (The
> sample implementation [2] uses SHA-1 and the authors subsequently
> suggested using SHA-2.) My investigation of extractors has lead me to
> believe that it much better to use an extractor that is seeded/keyed by an
> authenticated nonce. But, in J-PAKE, we can authenticate the key exchange
> but we can't directly authenticate the nonce.
>
> I saw Hugo Krawczyk's response in the thread "CMAC for Extraction" [3]
> that said "If your protocol cannot exchange a nonce, or can exchange it
> but cannot authenticate it (in which case the nonce can be chosen by an
> attacker) then replace N with a fixed value that is defined and wired it
> into the protocol as a constant. Choose N to be any 'random' string of the
> length of a CMAC key." But, it isn't clear to me how to evaluate the
> security of this.
>
> In TLS, with static-static (EC)DH key exchange, nonces do not seem to be
> authenticated except indirectly through the client finished message. Would
> copying that design be better or worse than using a fixed N value instead
> of a nonce?
>
> Thanks,
> Brian Smith
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 3 Nov 2010 18:56:54 -0400

If the nonces are NOT authenticated then it is better to use a fixed salt
value that cannot be chosen by the attacker. If the nonces are not
authenticated then the attacker can choose/influence their value. In
principle, though not necessarily a practical threat for common functions,
the attacker may be able to choose a salt value where the function is weak.
For example, imagine that AES under the all-zero key is weak (say, AES
outputs very non-random strings when keyed with all zeros). This would not
mean that AES is weak since the probability to choose the all-zero key in a
regular use would be 2^{-128} but it would be bad for the KDF application if
the attacker can force the all-zero salt.

As for TLS, the nonces would probably be authenticated via the finished
message. But if the key that you use to MAC the finish message is derived
using the nonces themselves then this MAC operation does NOT authenticate
the nonces (as the attacker may have chosen the nonces such that the salted
KDF will result in a predictable MAC key).

Does this answer your question?

Hugo

On Wed, Nov 3, 2010 at 3:07 PM, Brian Smith <[email-masked]> wrote:

> function as an extractor following Diffie-Hellman key exchange. (The sample
> implementation [2] uses SHA-1 and the authors subsequently suggested using
> SHA-2.) My investigation of extractors has lead me to believe that it much
> better to use an extractor that is seeded/keyed by an authenticated nonce.
> But, in J-PAKE, we can authenticate the key exchange but we can't directly
> authenticate the nonce.
>
> I saw Hugo Krawczyk's response in the thread "CMAC for Extraction" [3] that
> said "If your protocol cannot exchange a nonce, or can exchange it but
> cannot authenticate it (in which case the nonce can be chosen by an
> copying that design be better or worse than using a fixed N value instead of
> a nonce?
>
> Thanks,
> Brian Smith
>