[issue27297] Add support for /dev/random to "secrets"

Nick Coghlan added the comment: Please don't use /dev/random for anything, ever. It can block applications unpredictably for no good reason. -- nosy: +ncoghlan resolution: -> rejected status: open -> closed ___ Python tracker

[issue27297] Add support for /dev/random to "secrets"

Changes by Donald Stufft : -- nosy: -dstufft ___ Python tracker ___ ___ Python-bugs-list

[issue27297] Add support for /dev/random to "secrets"

Changes by Christian Heimes : -- nosy: -christian.heimes ___ Python tracker ___ ___

[issue27297] Add support for /dev/random to "secrets"

Donald Stufft added the comment: > It's just that the manpage for urandom (and in fact the comments in the > source code for /dev/random and /dev/urandom) both recommend using > /dev/random for these long-lived cryptographic keys. It's a hedge because of the bad behavior of /dev/urandom on

[issue27297] Add support for /dev/random to "secrets"

Larry Hastings added the comment: I understand. It's just that the manpage for urandom (and in fact the comments in the source code for /dev/random and /dev/urandom) both recommend using /dev/random for these long-lived cryptographic keys. Under normal circumstances I'd simply assume that

[issue27297] Add support for /dev/random to "secrets"

Donald Stufft added the comment: I will add, /dev/random is not going to *hurt* when generating long lived cryptographic keys (e.g. like your SSH keys) because that's something you're generally going to do once every couple of years and if it takes a few seconds longer because of snake oil

[issue27297] Add support for /dev/random to "secrets"

Donald Stufft added the comment: > So, you assert getrandom(0) and getrandom(GRND_RANDOM) return random bits of > identically high quality? Yes, except the latter will randomly block. > I'm curious about this political pressure you cite. Think about the last 4 days, now imagine that's

[issue27297] Add support for /dev/random to "secrets"

Larry Hastings added the comment: So, you assert getrandom(0) and getrandom(GRND_RANDOM) return random bits of identically high quality? I'm curious about this political pressure you cite. It seems bizarre to me that the Linux developers would bow to such a thing, given how they behave

[issue27297] Add support for /dev/random to "secrets"

Donald Stufft added the comment: No we should not use /dev/random (or GRND_RANDOM(. It's numbers are not "more random" than /dev/urandom outside of the narrow window of prior to /dev/urandom being fully seeded. In fact, on Linux both /dev/urandom and /dev/random use the exact same CSPRNG the

[issue27297] Add support for /dev/random to "secrets"

Donald Stufft added the comment: For more information, read http://www.2uo.de/myths-about-urandom/ . -- ___ Python tracker ___

[issue27297] Add support for /dev/random to "secrets"

New submission from Larry Hastings: Linux contains two separate sources for random numbers: /dev/urandom and /dev/random. On a reasonably-current Linux box, the urandom(4) man page states: As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH