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

[Hugo Krawczyk <[e-mail]>]

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 <[e-mail]> 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
>
> [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
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>