Cicero (cicero@redneck.efga.org)
13 Jul 1998 05:31:33 -0000
Bram wrote:
>
>One way of maintaining a pool of entropy is as follows:
>
>Pick a one-way hash function to use. The pool size in the same number of
>bits as the hash output.
>
>To incorporate a bitstring into the pool, first hash the bitstring, then
>xor the resust with the contents of the pool, then hash the result to get
>the new contents of the pool.
I think you can make this good method better by removing the second
hash.
Am I missing some attack you are protecting against, or other
advantage you get, by the second hash?
I believe all of your properties below still hold for the simpler
procedure, without the second hash. The simpler method is even more
concise.
A method should be as simple as possible, with the safety factors
added in at the end (identified as such). This will help reduce the
"voodoo factor", make it easier to analyse, make it easier to
implement correctly, make it run faster (until the safety factors go
back in) ...
>
>The above has the following properties:
>
>The entropy of the pool after a new bitstring is added will either be the
>old entropy of the pool plus the entropy of the bitstring or the length of
>the pool, whichever is smaller.
>
>An attacker can't track the internal state of the pool after missing even
>a single input.
>
>An attacker can't force the pool into a predictable state by feeding it
>bogus bitstrings.
>
>A good way of getting random numbers out of the pool is to compute the
>hash of it's negation and use that as the random output, then hash it's
>non-negated value to get the new value for the pool.
>
>It's missing a separate collection pool, but I think the above is
>otherwise a fairly secure technique.
>
>-Bram
Cicero
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:19 ADT