Marko Kreen <marko@l-t.ee> writes:
> After studying Fortuna more, I found out that I missed
> some of the details.
> - reseeding should happen only if pool #0 has aquired additional
> entropy.
> - a 'rekeying' operation should happend after each request and
> also after 1M of extracted data. That means taking next two
> blocks and using it as new key.
> - Fortuna _really_ wants entropy sources to be somewhat unpredictible.
> So roll dice when adding it and also add them to pools randomly,
> not sequentially.
> This hopefully makes harder for someone to doctor with the
> internal state (as in our case user can directly control
> what goes into it).
> That also drops the idea of several sources - which really
> fits more to hardware backed event sources.
> - add a really obvious obfuscation: take the absolutely first
> block be initial counter value. If Fortuna (AES to be exact)
> is secure with known counter value, then it should be also
> secure with unknown counter value. This does not go against
> the important property of counter - that the bit-pattern repeat
> period should be as long as possible.
> - S2K functions should use px_get_pseudo_random_bytes not
> px_get_random_bytes.
Applied.
regards, tom lane
