Subject: [IPsec] #55: Exponential reuse - reference

From: Yaron Sheffer <[email-masked]>
Date: Sun, 7 Dec 2008 17:09:23 +0200

Yaron: 2.12: Exponential reuse - can we give a reference on how to do it
securely?

Room: Does anyone have a reference?  There may be a minor change involving
multiplying old exponential by g (mod p) to produce a different exponential.
When exponential reused, nonces force
generated keys to be different.  The request is for an external crypto or
security analysis reference on this topic.

[This is obviously still open - Yaron].

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 9 Dec 2008 15:11:36 -0800 (PST)

Hi Yaron,

  I think the notes on this discussion missed something. If you multiply
the old exponential by g mod p the generated keys will be different
regardless of the nonces. g^x and g^y gives g^xy, g^(x+1) and g^(y+1)
gives g^(xy+x+y+1) which will be quite different. The resulting keys will
be random to an attacker but will be related, and that's where the problem
arises. "How to do it securely" depends on what kind of security you're
talking about.

  It appears that a scheme that reuses D-H exponentials in this way can
achieve IND-CPA-- indistinguishable under a chosen plaintext attack. That
is, I believe, the weakest security notion based on the theorem of Bellare,
Desai, Pointcheval, and Rogaway. I don't know whether IKEv2 has been proven
secure under any security notion but I think if it can be proven to be
IND-CPA then reusing Diffie-Hellman exponentials in this way will not
weaken its security. If it's proven to be secure against a stronger notion
then reusing Diffie-Hellman exponentials will weaken it to IND-CPA. (NB:
I am not a cryptographer).

  As far as a reference is concerned, there is a nice discussion of
this in section 4.3.0.2 of "Just Fast Keying: Key Agreement in a Hostile
Environment", Aiello et al, ACM Transactions on Information and System
Security, Vol. 7, No. 2, May 2004.

  Dan.