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

RE: Re-keying Issues Document



Can you suggest where there can be 128 bits of entropy
available at the desired intervals, from an arbitrary
computing system in the *general case*?


On 02-Oct-98 Paul Koning wrote:
>>>>>> "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: