[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Re-keying Issues Document

>>>>> "M" == M C Nelson <mcnelson@mindspring.com> writes:

 M> Since rekeying is current in the discussion, I'd like to take this
 M> as an opportunity offer another thought related to rekeying.

 M> It is suggested by some that frequent rekeying is a way to provide
 M> perfect forward secrecy.  I would like to question that hypothesis
 M> as it applies to IPSEC, per the assumption that few platforms will
 M> have a source of true random numbers.

 M> For any software key generator, any new key will be predictable
 M> given a knowledge of the algorithm and its inputs.  An example
 M> would be,

 M> K-new = func( seed, T ),

 M> where T is any information that varies from one invocation to the
 M> next.  T could be the previous result or a clock, or
 M> what-have-you.  In any case T is also predictable (else we're
 M> talking about random number hardware).  This will be the situation
 M> for any rekeying system that needs to run without a source of true
 M> random numbers.

 M> Despite any amount of rekeying, there is still really only one
 M> secret, the seed....

If your key generator is that poorly done, I would agree.  And a
hardware generator is clearly a Good Thing -- IF it is done well,
which is not at all easy to verify.

But in fact you can do a great deal better with software only.
There's a good discussion in RFC 1750, as I recall.

For example, rather than just "stir in" the current time, or the
previous result, you can "gather entropy" on an ongoing basis.  There
are lots of source of entropy in any computer system, especially in
things that have user interfaces, but even in those that do not.
While any one piece you stir in may have very little entropy, perhaps
even a fraction of a bit, still if you keep at it you will get more.

Interestingly enough, this suggests that a system may want to impose
or at least recommend an upper bound on the rate of key generation: it 
does no good to generate N bits of new key if you don't have somewhere 
near N bits of new entropy by then.  In other words, the rekeying
volume parameter should have a lower bound, which is implementation
dependent. 

	paul
Follow-Ups: References: