headers
Brian Smith | 3 Nov 2010 20:07

Extractor for use with PAKE protocols (specifically J-PAKE) / unauthenticated nonces

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
Permalink | Reply | 2 comments |
headers
Dan Harkins | 3 Nov 2010 20:55

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


  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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hugo Krawczyk | 3 Nov 2010 23:56
Picon

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

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 <bsmith <at> mozilla.com> 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
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg <at> irtf.org
http://www.irtf.org/mailman/listinfo/cfrg
Permalink | Reply | 0 comments |
headers
Sean Turner | 14 Nov 2010 14:55

draft-turner-sha0-sha1-seccon-01.txt

I submitted a new version, but I can't find the I-D Action email. 
Here's the link:
http://tools.ietf.org/id/draft-turner-sha0-sha1-seccon-01.txt

Changes include:
  - Removing 2119 language
  - Adding Paul Hoffman as author
  - Reworked the pre-image and second pre-image text
  - (significantly) reworked the guidance section

Comments are welcome.  Please use the saag <at> ietf.org list.

Cheers,

spt
Permalink | Reply | 0 comments |

Gmane