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

Re: Re-keying Issues Document


On 07-Oct-98 Paul Koning wrote:
>>>>>> "M" == M C Nelson <mcnelson@mindspring.com> writes:
>
> > On 05-Oct-98 Paul Koning wrote:
> >> ...  
> >> 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.
> >
> >...
> > 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.
>
>I keep wondering what exactly the point is you're trying to get
>across.
>
>It seems to me we have agreement that a software key generator that
>does not have any external source of entropy is vulnerable.  And also
>that sources of entropy are slippery things that have to be analyzed
>on a case by case basis; there is no "general" source of entropy.
>
>On the other hand, it sounds at times like you're saying that the only 
>sources of entropy are purpose-built chunks of hardware like noise
>diodes or radioactive sources.  If that's the point, I disagree, and I 
>would object to documents that claim this is so.  
>
>In fact, any source of entropy is hard to build.  They all require
>careful analysis as to bit rate and fault properties.  That's no less
>true for purpose-built "true random number generators" as it is for
>processes that as a side effect can act as an entropy source (like
>disk drives).
>
>As I mentioned, I've done that analysis for the entropy sources in my
>system.  You dismiss that work by the term "anecdote" without knowing
>anything about it.  If you want "proof" of randomness, I suggest you
>may be asking for a proof of a negative.  For any entropy source, all
>you can expect is a careful analysis and an engineering judgement that
>it has the right properties.  To judge the merits of such an analysis
>you have to look at the particular system and the work that was done
>with it; you can't just sit and write adjectives like "anecdotal".
>

By your own comment, this is an analysis on your machine, hence anecdotal.
(Quod Erat Demonstratum).

>The tradeoff on how key generation should work has to be an
>implementation decision.  Some systems have relatively high rate
>entropy sources, and these can therefore support high rate key
>generation easily.  Others do not, and have to be more careful in how
>they do key stream extension.  I agree that "it is simply impossible
>to say that the general case machine..." so I would not want to
>prescribe a solution, but rather point designers at good principles
>such as those in RFC 1750.

 `I agree that "it is simply impossible
  >to say that the general case machine..."'

  Wonderful.  Thank you.  


>
>	paul
References: