[issue29790] Optional use of /dev/random on linux

[STINNER Victor]

STINNER Victor added the comment:

You can already use os.getrandom() if you want /dev/urandom. And as you
wrote, it is easy to inherit from SystemRandom if you need something else
than bytes.

I am strongly opposed to use /dev/random because most users misunderdood
RNG znd so will use /dev/random for *bad* reason.

There is no need to extend the stdlib. I suggest yo close this issue as
WONTFIX.

--

___
Python tracker 

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

[issue29790] Optional use of /dev/random on linux

[Nick Coghlan]

Nick Coghlan added the comment:

To provide some additional context to that answer: the problem isn't with folks 
wanting direct access to their hardware entropy devices as such.

There are plenty of options for that (such as exposing it as a file descriptor 
distinct from both /dev/random and /dev/urandom), but going through /dev/random 
(or calling "os.getrandom(n, os.GRND_RANDOM)") isn't one of them.

Instead, /dev/random consumes the same kernel CSPRNG that /dev/urandom does, it 
just adds an extra check to make it block when the kernel's collected entropy 
estimate happens to be low.

So this isn't something we want to expose or explain to Python users in general 
- instead, it's something that only folks doing highly specialised work 
involving hardware security modules might be interested in, and hence can be 
safely left to third party tools and frameworks, rather than being something 
that would ever be shipped by default as part of the reference interpreter and 
standard library.

--

___
Python tracker 

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

[issue29790] Optional use of /dev/random on linux

[Nick Coghlan]

Nick Coghlan added the comment:

This RFE is unfortunately based on some incorrect assumptions about the way 
Linux kernels use CSPRNGs and entropy pools. Using /dev/random isn't magically 
more secure than /dev/urandom, it just makes your applications less reliable 
for no good reason.

Folks are free to do that through an extension module if they really wish to do 
so, but it's not an option we're interested in supporting in the standard 
library.

This is a good article providing some additional background on that topic: 
http://www.2uo.de/myths-about-urandom/

There was one genuine problem with /dev/urandom (it could return potentially 
predictable values if the entropy pool hadn't been adequately seeded), but 
Victor addressed that in PEP 524 by switching to the blocking variant of the 
getrandom() syscall (when available) rather than using the file descriptor 
interface.

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue29790] Optional use of /dev/random on linux

[Ivan Anishchuk]

Ivan Anishchuk added the comment:

Victor, I suppose you don't happen to have a good entropy source? :) I cannot 
really stress the word "optional" enough here. And I understand why most user 
wouldn't want this. That's why I'm proposing to make it optional.

As per PEP, "The /dev/random device should only used for very specific use 
cases." and that's exactly what I'm proposing, a special option for special use 
cases. (Speaking of options, it would've been nice to have more of those, I 
would really like to have an easy way to access an entropy source directly, not 
through system PRNG, for generating keys and like. But devices and interfaces 
can be different so it's out of scope for this proposal.)

To be absolutely clear: what I'm proposing is a small improvement for linux 
users who have a good entropy source (e.g. a hardware TRNG) and specifically 
opt for this feature setting an environment variable (or by other means). 
Without affecting anyone else under any circumstances.

--

___
Python tracker 

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

[issue29790] Optional use of /dev/random on linux

[STINNER Victor]

STINNER Victor added the comment:

I'm opposed to use blocking /dev/random instead of /dev/urandom: see PEP
524 for the rationale.

--

___
Python tracker 

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

[issue29790] Optional use of /dev/random on linux

[Steven D'Aprano]

Changes by Steven D'Aprano :


--
nosy: +haypo, ncoghlan, steven.daprano

___
Python tracker 

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

[issue29790] Optional use of /dev/random on linux

[Ivan Anishchuk]

New submission from Ivan Anishchuk:

Right now secrets module uses SystemRandom which is hardcoded to use 
os.urandom() which is fine for most users but some have good hardware sources 
of entropy (or otherwise replenish entropy pool) in which case it would be much 
better to use getrandom() with GRND_RANDOM flag i.e. to read from /dev/random 
pool.

Simply subclassing SystemRandom is not enough, the idea is to make it possible 
for every library and program to use the big entropy pool if it's available. So 
I'm thinking it would be best to configure it with an environment variable, 
something like PYTHONTRUERANDOM or PYTHONDEVRANDOM.

Admittedly, only a small subset of users would benefit from this but changes 
required are also small and I'm willing to do all the work here. Are there any 
reason this patch won't be accepted? Any preferences regarding variable name?

--
components: Library (Lib)
messages: 289410
nosy: IvanAnishchuk
priority: normal
severity: normal
status: open
title: Optional use of /dev/random on linux
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