Re: [patch 2/3] Fortuna fixes

Marko Kreen <marko(at)l-t(dot)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