[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits? (original) (raw)
Tim Peters tim.peters at gmail.com
Sat Jun 11 22:21:41 EDT 2016
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Sebastian Krause]
... Ideally I would only want to use the random module for non-secure and (in 3.6) the secrets module (which could block) for secure random data and never bother with os.urandom (and knowing how it behaves). But then those modules should probably get new functions to directly return bytes.
secrets.token_bytes() does just that, and other token_XXX()
functions return bytes too but with different spellings (e.g., if you
want, with the byte values represented as ASCII hex digits)..
I believe everyone agrees token_bytes() will potentially block in 3.6
(along with all the other secrets facilities) on platforms
supporting getrandom().
You're right that random doesn't expose such a function, and that
the closest it gets is .getrandbits() (which returns a potentially
giant int). So far, nobody has proposed adding new functions to
random.
- Previous message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Next message (by thread): [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]