summaryrefslogtreecommitdiff
path: root/src/winrand.c
Commit message (Collapse)AuthorAgeFilesLines
* Py3k cleanup: Module initializationDwayne Litzenberger2013-07-141-11/+25
|
* Py3k cleanup: Always use tp_getattroDwayne Litzenberger2013-07-141-15/+9
|
* Py3k cleanup: PyMODINIT_FUNCDwayne Litzenberger2013-07-141-2/+1
|
* Py3k cleanup: PyVarObject_HEAD_INITDwayne Litzenberger2013-07-141-5/+0
|
* Py3k cleanup: PyType_ReadyDwayne Litzenberger2013-07-141-2/+2
|
* Py3k cleanup: staticforward and Py_TYPEDwayne Litzenberger2013-07-141-5/+0
|
* Py3k cleanup: Define PyInt_FromLong for Python 3.x and use itDwayne Litzenberger2013-07-141-2/+1
| | | | | | This is the first of a series of changes that aims to reduce code duplication between the Python 3 and Python 2 versions of the C extensions.
* Add pycrypto_common.h and clean up a bunch of miscellaneous includes & typedefsDwayne Litzenberger2013-04-211-2/+1
|
* Changes to allow pycrpyto to work on Python 3.x as well as 2.1 through 2.7Thorsten Behrens2010-12-281-12/+99
|
* winrand.c: Replace the legal noticeDwayne C. Litzenberger2009-08-021-5/+16
| | | | I have permission to do this. See the LEGAL directory.
* Fix compiler warnings (MinGW/Win32)Dwayne C. Litzenberger2008-09-151-4/+3
|
* setup.py: Resurrect the winrandom module (Win32)Dwayne C. Litzenberger2008-09-151-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [project @ moraes-20030201084644-3bb09e6dfb7e5bc5]moraes2003-02-011-34/+302
| | | | | | | | | | | | | | | | | | | [project @ 2003-02-01 00:46:43 by moraes] Changed winrandom module interface to a "new" function that returns an object with a "get_bytes" method, which can be called repeatedly. Module contains a list of providers and provider types that can be passed to new(), and get_bytes() accepts an optional string of userdata which can be stirred into the mix. Examples: data = winrandom.new().get_bytes(10) w = winrandom.new(winrandom.MS_ENHANCED_PROV, winrandom.PROV_RSA_FULL) data = w.get_bytes(10) data = w.get_bytes(10) ...
* [project @ moraes-20030131142514-2d6b88f9580ae6ee]moraes2003-01-311-7/+19
| | | | | | | [project @ 2003-01-31 06:25:14 by moraes] Added provider and provtype options so that I can try this with Intel RNG driver. (provider "Intel Hardware Cryptographic Service Provider", provtype 22)
* [project @ moraes-20021023115220-7b961936f27ecd5b]moraes2002-10-231-0/+86
[project @ 2002-10-23 04:52:20 by moraes] Added Crypto.Util.winrandom.winrandom C extension code to get randomness from Windows CryptGenRandom.
View Lorry Controller Status