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

Re: Re-keying Issues Document




On 02-Oct-98 Donald E. Eastlake 3rd wrote:
>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.

1. Bear in mind that you need to build up something like 128 bits
of randomness at the desired intervals.

2. The contents of traffic are not necessarily random.

3. Using the contents for key generation adds another possibility
for cryptoanalysis, which will need to be studied on a case by
case basis.

>
>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.

Here, you missed the point.  The attacker attacks the seed.  In the
absence of an additional random input, this is the only secret in
the system.  Everything else is derived from it.

>
>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. Nel
son" 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: