This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author nickm
Recipients
Date 2004-04-25.18:55:33
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=499

This patch would be tremendously valuable to me.  I've had
to maintain similar code for a couple of projects, and
having this functionality in Python would make my life one
step similar.

A few comments:
- According to MSDN, CryptGenRandom exists on Win98 and
later, and on Win95 OSR2, and on Win95 with IE 3.something
or later.

- It's necessary on some platforms, and for some
applications, to use a device other than /dev/urandom. 
(Some high-security code demands /dev/random; some OpenBSD
people swear by /dev/arandom; and so on.)

- Maybe it would be a good idea to only implement the
windows CryptGenRandom part in C, and implement the Unix
part in Python.  Then you could expose the windows code as
(say) "entopy.win_entropy(nBytes)", the unix part as (say)
"entropy.unix_entropy(nBytes, file='/dev/urandom')", and
have "entropy.entropy(nBytes)" be a cross-platform wrapper.
 This would cut down on the amount of C you need to add;
make it easier to switch entropy devices; provide better
errors when /dev/urandom is unreadable; and provide users
the option to trust only certain entropy sources.

- I believe that you're right not to worry too much about
the performance here.

- According to the MSDN documentation for
CryptAcquireContext, if your first call fails, you're
supposed to retry with a final argument of CRYPT_NEWKEYSET
before you report an error.  I don't know when/if this is
necessary, or whether there are hidden gotchas.

Once again, this patch is a great idea, and I heartily hope
that it gets in!
History
Date User Action Args
2007-08-23 15:37:09adminlinkissue934711 messages
2007-08-23 15:37:09admincreate