Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:22 ADT
Bill Frantz (frantz@communities.com)
Tue, 14 Jul 1998 11:55:36 -0700
on Sun, 12 Jul 1998, bram <bram@gawth.com> wrote:
>On Sat, 11 Jul 1998, Bill Frantz wrote:
>> The entropy pool consists of an array of 16 MD5 hashes.
>
>Why 16? You said earlier that you think 160 bits of entropy is enough, so
>it's questionable what having a larger pool buys you. I think having a 160
>bit pool and using a technique based on sha1 or ripemd160 can make a
>perfectly good PRNG.
The general reason for using more than one block with SHA or ripemd160 is
trying to build in a wide margin of safety. 256 bytes of memory is cheap
enough that it seems a reasonable cost for that margin.
>> Each time new entropy is added to the pool, we replace the next hash (in
>> a circular manner) with MD5(entire pool || new entropy || current value
>> of the CPU cycle counter).
>
>In general, you want to hash any new entropy coming in before
>incorporating it, to thwart malicious attackers who have the ability to
>feed arbitrary bit strings into your PRNG.
I don't believe this is necessary if you are concatenating the new entropy
with the old pool and feeding it to a secure hash (MD5). The output of the
hash function will depend on all of the input bits. As such, even if the
input is completely known by your attacker, the bits from the pool remain
unknown and therefor the output of the hash remains unknown.
In any case, one of the assumptions is that the machine is not hacked so it
is hard to see how these malicious attackers get access to the PRNG API.
>Also, it's important to maintain a pool of entropy outside your the core
>of your PRNG for putting new entropy into and only incorporate it when
>it's entropy count gets high enough, to prevent continuation attacks.
>Consider the case where an attacker finds out your internal state and can
>see all output from the PRNG and all entropy is being added in one bit
>chunks. If the attacker gets to see at least some output after each new
>piece of entropy is added, he on average only needs to make one guess as
>to what the added bitstring was before being able to confirm it based on
>output. If, on the other hand, the strings containing entropy were
>combined together and only used once their combined entropy hit 160 bits,
>the attacker would be totally lost.
This attack violates the unhacked assumption big time. Given that the
attacker has that level of access to the running code, why not just send
out the bits as they are generated.
I think the rest of bram's comments have been discussed by others in other
mail.
Someone else, and I'm sorry I don't have the email here to quote, suggested
that capturing entropy from mouse events would not generate good entropy.
There are actually several sources of hard-to-predict entropy in mouse events:
(1) While the user may only be selecting a small number of menu items, the
actual pixels they select are much harder to reproduce. One way of testing
this is to instrument a UI to display to last pixel selected (on mouse down
or mouse up) in some corner of the window. Then see how easy it is to
select the same pixel each time.
(2) The value of the CPU counter when the mouse down/up event occurs
depends on when the user actually provided the input. While this time may
be quantitized by the mouse scanning routines, differences of 1/10 a second
are easily within the expected variance of user response, giving a source
of hard-to-predict entropy.
If you need to gather a lot of entropy quickly, mouse tracking, where you
(or the OS) poll the mouse location 20 times a second or so, is the way to
go. This technique is what PGP 5.x uses. However, it uses a lot of CPU,
so it expensive when you are in the, "let's add more entropy because we're
paranoid" mode and have an application which can use all the CPU on its own.
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:22 ADT