setup.py: Resurrect the winrandom module (Win32)

There are three things that, when combined, produce exploitably-weak random
number generation reminiscent of the infamous Debian libssl fiasco
(CVE-2008-0166):

    1. Microsoft Windows

    2. A long-standing bug in PyCrypto's setup.py that omits the "winrandom"
       module from the build procedure, causing RandomPool to be seeded weakly
       when it is instantiated.

    3. A tendency among PyCrypto's users to (incorrectly) treat RandomPool as
       a portable substitute for reading from /dev/urandom.  RandomPool was
       never intended as a complete RNG, but I have seen several cases where
       it has been treated as one. (See footnote.)

This commit provides a quick fix for #2.  Future work will attempt to fix #3 by
providing users with a "works out-of-the-box" random number generation API.
Fixing #1 probably won't happen any time soon, though reports of the initial
success of Windows Vista suggest that Microsoft may be working hard on the
problem.

Footnote:

For more information about the misuse of RandomPool, see:

    http://lists.dlitz.net/pipermail/pycrypto/2008q3/000000.html
    http://www.lag.net/pipermail/paramiko/2008-January/000599.html
    http://www.lag.net/pipermail/paramiko/2008-April/000678.html
    https://bugs.launchpad.net/pycrypto/+bug/249765

1 files changed, 10 insertions, 1 deletions

diff --git a/src/winrand.c b/src/winrand.c
index 8c82bd4..884b734 100644
--- a/src/winrand.c
+++ b/src/winrand.c
@@ -97,7 +97,8 @@ winrandom_new(PyObject *self, PyObject *args, PyObject *kwdict)
 		return NULL;
 	}
 	if (! CryptAcquireContext(&hcp, NULL, (LPCTSTR) provname,
-				  (DWORD) provtype, 0)) {
+				  (DWORD) provtype,
+				  CRYPT_VERIFYCONTEXT | CRYPT_SILENT)) {
 		PyErr_Format(PyExc_SystemError,
 			     "CryptAcquireContext for provider \"%s\" type %i failed, error 0x%x",
 			     provname? provname : "(null)", provtype,
@@ -362,5 +363,13 @@ FIPS-approved. Obviously FIPS-140 compliance is necessary but not
 sufficient to provide a properly secure source of random data. 
  
 */
+/*
+[Update: 2007-11-13]
+CryptGenRandom does not necessarily provide forward secrecy or reverse
+secrecy.  See the paper by Leo Dorrendorf and Zvi Gutterman and Benny
+Pinkas, _Cryptanalysis of the Random Number Generator of the Windows
+Operating System_, Cryptology ePrint Archive, Report 2007/419,
+http://eprint.iacr.org/2007/419
+*/
 
 #endif /* MS_WIN32 */