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

Re: Re-keying Issues Document



Steve,

So far, I haven't seen anything in the references that alters any element of
my thesis.

First of all, my central point is that software-only key generation combined
with frequent re-keying doesn't bode well for security. From the discussions
so far, it seems that this point is not contested.  (It seems that the
arguments apply to the BBS algorithm also).

Many of the papers that you and others have cited, try to find some hardware
source of randomness to mix in to the software key generation method.  This
takes us into the tangential question, is there as a general case, a source 
of randomness available to software?

I have maintained that one cannot say that in the general case there is a
source of randomness available, short of saying that the general case always
includes certain hardware or a human.  If you can point me to a cite which
otherwise constitutes a general case, I would be thankful.  The clock drift
method (which I have in my own notebooks from a long long time ago) by the
author's own admission, is not a general case solution, nor are the solutions
based on disk drives, or sound boards.  Moreover, we can expect that there
will soon be a large number of small networked devices that have single
clocks, no disk drives, and otherwise lots of variability in configuration.

Regards,
Mitch Nelson


On 07-Oct-98 Steve Bellovin wrote:
>In message <XFMail.981007143055.mcnelson@mindspring.com>, "Dr. M. C. Nelson" wr
>ites:
>> 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.
>
>Have you read any of the papers cited?  For example, try Davis et al.,
>http://world.std.com/~dtd/, on using disk drive air turbulence for
>randomness.  Cryptolib, by Lacy et al., uses timing jitter between
>different clocks, a technique used by some "real" hardware RNGs.
>
>Sure, it's hard to do right.  But blatant assertions that it can't
>be done simply don't hold.
>> 
>> 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.
>
>Have you read the Blum, Blum, and Shub paper cited here?  Have you
>looked at Wagner's set of pointers (http://www.cs.berkeley.edu/~daw/netscape-ra
ndomness.html)?


Follow-Ups: References: