Re: [patch 2/3] Fortuna fixes

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