[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits? (original) (raw)
Random832 random832 at fastmail.com
Fri Jun 10 17:14:50 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 ]
On Fri, Jun 10, 2016, at 15:54, Theodore Ts'o wrote:
So even on Python pre-3.5.0, realistically speaking, the "weakness" of os.random would only be an issue (a) if it is run within the first few seconds of boot, and (b) os.random is used to directly generate a long-term cryptographic secret. If you are fork openssl or ssh-keygen to generate a public/private keypair, then you aren't using os.random.
So, I have a question. If this "weakness" in /dev/urandom is so unimportant to 99% of situations... why isn't there a flag that can be passed to getrandom() to allow the same behavior?
- 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 ]