D-H key exchange - how does it work?

[hughes@ah.com (Eric Hughes)]

   > For D-H, the modulus must be transmitted in the clear.  Unless you use
   > a different modulus for each conversation, there is a persistency to
   > the moduli that gives rise to a pseudo-identity.

   You don't HAVE to transmit the modulus in the clear. 

But we were talking about changing moduli and its effect on traffic
analysis.  If you change the modulus each conversation, you have two cases:

  1. Transmit before the conversation
  2. Transmit at the beginning of the conversation

For case 1., you could, conceivably, transmit the modulus for the next
exchange in a previous (encrypted) conversation, but that introduces
lots of system complexity, state, and general nastiness.  If the
modulus is previously transmitted unencrypted, then we're back to the
beginning.

For case 2., you can transmit the modulus in the clear or encrypted.
If in the clear, then you have the TA issues as before.  If encrypted,
you need some method of generating an encryption key, like D-H, which
we're trying to do.  So you could use a fixed modulus to encrypt for a
second exchange; that's slow, and when the modulus goes, you reveal
the same TA data as before.  If you don't use D-H, and, say, public
key derived things are used, then you even more directly reveal TA.

The above analysis is not very rigorous.  It merely points out where
some of the problems are.

   Its often
   worthwhile to use D-H for key exchange even if both sides know the
   other's RSA public keys. 

It's called forward secrecy.  Sure.  But the issue at hand is TA.

Eric