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

[Nick Coghlan]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Donald Stufft]

Changes by Donald Stufft :


--
nosy:  -dstufft

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Christian Heimes]

Changes by Christian Heimes :


--
nosy:  -christian.heimes

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Donald Stufft]

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 early boot in a 
situation where it's highly unlikely that the randomly blocking behavior of 
/dev/random is going to matter.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Larry Hastings]

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 was correct and I'd follow their advice.

But you're claiming that there are extenuating political circumstances 
surrounding these statements and they should be ignored.  I trust your 
judgement and I'd be happy to see the secrets module do as you suggest.  But 
you must admit, this is a surprising state of affairs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Donald Stufft]

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 then who cares. It's not going matter once 
/dev/urandom is initialized (of course, it does matter if /dev/urandom hasn't 
been initialized yet). So it does guard against early on in the boot process in 
a way that /dev/urandom doesn't (but then, so does getrandom(0)).

It's obviously not acceptable for your webserver to randomly block for seconds 
at a time trying to generate signing keys for cookies just because of snakeoil 
though.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Donald Stufft]

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 happening on LKML where instead 
of having GvR disagree with you, you get told your parents should have aborted 
you.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Larry Hastings]

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 
on... well, every other topic.  Can you point me towards resources about this 
political squabble?

p.s. Yes, I've re-read the "myths about urandom" page many times this week.  
But there are enough experts on both sides of the topic that I don't know what 
to believe anymore.  Certainly I'm happy to leave it to you guys.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Donald Stufft]

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 only difference is that /dev/random does some snake oil 
to try and guess "how much random" is left (which experts widely agree is a 
load of manure) and will block randomly (pun intended) throughout the running 
of the system whenever it's snakeoil decides that it's "random is running low".

I know what the manpage says, it's basically an urban myth, unchanged largely 
because of political pressure

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Donald Stufft]

Donald Stufft added the comment:

For more information, read http://www.2uo.de/myths-about-urandom/ .

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Larry Hastings]

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 keys.

This seems to suggest that, in the eyes of its implementors, /dev/random 
returns ever-so-slightly superior random numbers, and that in certain limited 
circumstances you should prefer those.

AFAICT the secrets module doesn't make use of the /dev/random device on Linux.  
Should it?  (Or, in the likely case that we make the getrandom() function 
directly callable, should it call getrandom(GRND_RANDOM)?)


p.s. FWIW, Linux's /dev/urandom isn't considered a true CPRNG in all circles.  
This paper declines to call it simply either a CPRNG or a PRNG, instead 
christening it with the unfamiliar term "PRNG with entropy inputs".

https://eprint.iacr.org/2012/251.pdf

p.p.s. I went ahead and nosied the "cryptography" "interest category" from the 
nosy list.  Neat!

--
assignee: steven.daprano
components: Library (Lib)
messages: 268243
nosy: christian.heimes, dstufft, gregory.p.smith, larry, steven.daprano
priority: low
severity: normal
stage: test needed
status: open
title: Add support for /dev/random to "secrets"
type: enhancement
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com