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

Re: Re-keying Issues Document

Steve,

The points in my letter (concerning rekeying) were

 (1) for a software key generator there is really
 only one secret.

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

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.


Mitch Nelson


On 02-Oct-98 Steve Bellovin wrote:
>In message <XFMail.981002174038.mcnelson@mindspring.com>, "Dr. M. C. Nelson" wr
>ites:
>> David,
>> 
>> Perhaps I was overly succinct in my previous note. I am sorry that
>> I can not think of a nice way to say that I think you missed the point.
>
>In that case, perhaps you could expand on your previous note?  I
>personally thought that Wagner's reply was quite to the point.
>
>Your message (I assume that you're talking about your message of
>13:53:33, 1 Oct 1998, <XFMail.981001160639.mcnelson@mindspring.com>, in
>the archives on ftp.tis.com -- the headers show that that's the note
>Wagner responded to) complained that (a) the attacker "only" has to
>guess the original seed, and (b) anything else T that you stir in isn't
>really random.  Wagner responded to point (b), showing (via a Web page
>with a collection of excellent links) that it is feasible to get a
>*random enough* T to add to the PRNG.  He further observed that one
>must be careful in how one does this -- an implementation note, if you
>will.
>
>Your central claim is that we all need hardware random number
>generators.  I don't think anyone here would dispute that; certainly I
>won't.  I will note, though, that bad use of hardware RNGs is very
>dangerous, and may fall victim to some of the same attacks that Wagner
>and others discuss.
>
>The bad thing about a RNG is that you never really know if it's working
>right.  Furthermore, many designs are sensitive to temperature,
>electrical noise, etc.  I assert that a good PRNG seeded by a true RNG
>is -- in practice -- far more secure than an RNG used directly.  (Some
>may recall the design described by Denning (but later disclaimed) for
>generating Clipper unit keys.  It was based on triple-Skipjack in EDE
>mode, with (apparently) true-random keys.  Some people criticized it
>for not being based solely on true-random generators.  I think that the
>designers were rather more cautious.
>
>I would also note that most true RNGs are rather slow.  If you go to
>that well too often, you'll end up without enough random bits -- see
>Wagner's point, op cit.
>
>The bottom line, though, is this:  we have three possible tools
>to use here:  true randomness, a secret seed, and a combining function.
>We have limited amounts of true randomness available; attached RNGs,
>though certainly very helpful, are not a substitute for the other
>two.  We can skip the secret seed, if we have enough true randomness;
>however, the cost of using it is low, and (if it is long enough and
>secret enough) it may compensate to some extent for the lack of
>true randomness.  Finally, we have the combining function.  Wagner's
>point is that you have to be very careful in how you use such functions,
>or you won't get the output strength desired.
Follow-Ups: References: