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

Re: Re-keying Issues Document


From:  "Dr. M. C. Nelson" <mcnelson@mindspring.com>
Message-ID:  <XFMail.981002174953.mcnelson@mindspring.com>
In-Reply-To:  <199810021407.KAA19267@torque.pothole.com>
Date:  Fri, 02 Oct 1998 17:44:31 -0400 (EDT)
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc:  ipsec@tis.com

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

Only if you need all new randomness.  Every single bit of entroy you
add helps.

>2. The contents of traffic are not necessarily random.

If the message conveys no information, why are you sending it?  Even
if some messages are like that, those which are not still add entropy
making prediction by the bad guys harder.

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

It's not "using the contents for key generation".  I'm not talking
about some autokey system. It's using the contents to add entropy to
your pool from which the key is generated.  Assuming you hash it in
using a modern strong one-way function like SHA1 as the basic building
block, I don't see the problem.  If you have a method of deriving a
key from your entropy pool that includes a functions which inverts
SHA1, I'd like to know about it.

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

Well, I was reading my mail in inverse chronological order so I hadn't
seen your original message and was just responding to the message
below.

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
References: