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

Re: Re-keying Issues Document

See RFC 1750.

If there is traffic you are trying to secure then it is presumably not
known to bad guys and including anything about this taffic in the
random number generation should help.  And, if you use good
techniques, even if the gad guys know that input to your randomness
generator, it should be no worse than not inputting it at all.  All
that is required is that out of all the inputs there be enough
entropy.

On the other hand, if you have a strong initial seed, you can use the
Blum-Blum-Shub or other methods to generate a cryptographcially strong
sequence of keys where learning a value in the sequence is of no help
in finding earlier or later values (see section 6.3.2 of RFC 1750).
This eliminates the need for additional input.

Donald

From:  Dan McDonald <danmcd@Eng.Sun.Com>
Message-Id:  <199810012347.QAA17546@kebe.eng.sun.com>
To:  mcnelson@mindspring.com (Dr. M. C. Nelson)
Date:  Thu, 1 Oct 1998 16:47:18 -0700 (PDT)
Cc:  ipsec@tis.com
In-Reply-To:  <XFMail.981001160639.mcnelson@mindspring.com> from "Dr. M. C. Nelson" a
t Oct 1, 98 01:53:33 pm

>Mitch,
>
>These are good points, and provide strong arguments for real HW random number
>generators.  One small nit, though...
>
>> For any software key generator, any new key will be predictable
>> given a knowledge of the algorithm and its inputs.  An example
>> would be,
>> 
>>     K-new  =  func( seed, T ),
>> 
>> where T is any information that varies from one invocation to the
>> next.  T could be the previous result or a clock, or what-have-you.
>> In any case T is also predictable (else we're talking about random
>> number hardware).
>
>Is T really predictable?  I ask this because if I frequently rekey based on
>the number of bytes I transmit, T will vary based on a human's input.  Human
>input is not very predictable.  If T is something along the lines of a
>nanosecond timer, the human input differences amplify.
>
>I'm not saying we don't need better randomness.  Maybe I'm arguing that
>byte-based lifetimes provide better security, because of the unpredictability
>of humans using those bytes.
>
>Dan
Follow-Ups: References: