[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.981004004115.mcnelson@mindspring.com>
In-Reply-To:  <199810022223.SAA07010@postal.research.att.com>
Date:  Sun, 04 Oct 1998 00:28:33 -0400 (EDT)

>Steve,
>
>The points in my letter (concerning rekeying) were
>
> (1) for a software key generator there is really
> only one secret.

There is no reason why you can't continually be adding entropy to your
secret pool so I don't see that this need be true in a practical
sense.

> (2) repeated generation of keys from that single
>  secret, can give away information about the secret.

They "can".  But cryptographically strong techniques, such as the Blum
Blum Shub method, provably do not, although they are computationally
intensive.

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

I don't know what you mean by "the general case" but if your machine
has a disk drive, for example, you can generate true randomness,
although not very quickly.

>Mitch Nelson

Donald

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


References: