[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re-keying Issues Document
On 05-Oct-98 Paul Koning wrote:
>>>>>> "M" == M C Nelson <mcnelson@mindspring.com> writes:
>
> > Steve, The points in my letter (concerning rekeying) were
>
> > (1) for a software key generator there is really only one secret.
>
>That's true. If ALL you use is a key stream extender without ever
>stirring in any entropy.
>
>Of course, if someone builds a key generator without ever reading RFC
>1750, there's not much we can do to help him.
>
> > (2) repeated generation of keys from that single secret, can give
> > away information about the secret.
>
> > (3) therefore, it is perhap better to simply use a very good
> > secret to begin with and only change it with proper true random
> > input or when warranted, or perhaps otherwise, infrequently.
>
> > A discussion of how one finds some source of randomness is not to
> > the point. Thats not the case being discussed.
>
>So what is the case being discussed? The one where someone doesn't do
>what RFC 1750 recommends, but instead simply extends a bitstream
>without ever stirring in randomness? I suppose it might be useful to
>say "don't do that". I don't see much sense in spending any more
>words than that explaining how to "improve" on such a fundamentally
>broken approach.
>
> > Also, the claim that one can rely on adequate randomness being
> > available in the general case without hardware specific to that
> > purpose, is hard to believe. There are lots of systems that deal
> > with lots of nearly repetitive or predictable stuff. The banking
> > and financial industries are full of them.
>
>I don't remember such a claim being made. If you're referring to my
>comments, I was referring to specific analysis of specific systems.
>As Don pointed out, if it has a disk it has a random number
>generator. And my observation is that even systems with no disk may
>have low rate sources of entropy. At least, the one analyzed does.
>
Simply not true in the general case. And, the observation
referred to can only be an anecdote, not a proof.
>If your point is that it is possible to build systems where no
>adequate source of entropy is available, I agree that this might be
>so. If you have such a system, you can't build an adequate
>implementation of IKE on it until you change the hardware to supply a
>source of entropy.
>
>But if your claim is that the only useable source of entropy is
>devices purpose-built for the specific job of generating "true random
>numbers" I believe you will find ample data contradicting that, in
>places such as RFC 1750 and elsewhere.
>
I admire you vehement enthusiasm to defend your work. Nonetheless
there are plenty of machines in the world that have predictable inputs,
states, and outputs. That in general terms is what a computer is.
No amount of anecdotal sampling of a limited range of cases will
change that fact. Moreover, with network appliances on the way,
there will no doubt be many more machines that flagrantly violate
your thesis.
In any case, the point is that you can be much better off by simply
using a very good key (with lost of bits) and changing it less
frequently. It is simply impossible to say that the general case
machine for which a network layer standard must apply, will always
have the necessary randomness available to safely generate good
keys at a substantial frequency. And it is simply impossible to
say that any pure-software-key-generator acting in combination with
encryption of datagrams is not going to open some cryptoanalytic door
except on a case by case basis.
> paul
Follow-Ups:
References: