Following two patches add Fortuna PRNG to pgcrypto.  I think
this is needed to really complete the 'no hand-config' direction
of pgcrypto.

Patch #1 adds implementation of SHA2 hashes (SHA256/384/512).
They are required for Fortuna.  As they are replacements
for SHA1 (which was replacement for MD5), they would be good to
have anyway.

Patch #2 adds implementation of Fortuna, plus reorganizes random
functions a bit.  random.c is made 'system randomness' provider,
for initial seeding of PRNG.  There I put 2 randomness sources
for Windows, /dev/urandom reader, and a fallback provider,
that does the getpid/gettimeofday stuff.

The idea is to initially seed Fortuna with randomness from
system and later feed SHA1 of user data into it too.  Just
to keep it from degenerating into pure PRNG.

I looked at various PRNGs, and Fortuna seemed to best fit pgcrypto
situation.  Fortuna predecessor, from same authors, Yarrow -
does not fit here as it needs precise accounting of entropy.
PRNGs based on stream-ciphers also do not fit as they cannot
handle feeding of dubious quality entropy.  (And using just a PRNG
without entropy feeding is not secure enough for session keys.)
Fortuna does not need entropy accounting, in exchange it wastes
entropy - keeps some of away from current output.


I know, this is past the feature freeze, but in a way its not
a new feature, rather is enables a already accepted (?)
feature on a rather common configuration (no-OpenSSL).
In particular, I am thinking about win32 port.

Also, the goal for the PGP work was to replace the current
encrypt() code, thus is needs also work everywhere encrypt()
works.  Without strong PRNG included, this goal is not filled.


PS. If the inline patches bother, I can send them attached.
Just that I use 'quilt' for preparing them, and it does not
have option to send them as attachments.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to