[issue22542] Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present

[STINNER Victor]

STINNER Victor added the comment:

"Trying to run the python interpreter in a chroot fails if /dev/urandom is not 
present."

The workaround is simple: fix your chroot to correctly expose /dev/urandom in 
the chroot. It's a common and known issue, no?

Since the issue is almost dead since 2 years and I don't know if arc4random() 
is suitable for os.urandom(), I close the issue. If you want to reopen it, 
please come back with more information on arc4random() security ;-)

--
resolution:  -> out of date
status: open -> closed

___
Python tracker 

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

[issue22542] Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present

[STINNER Victor]

STINNER Victor added the comment:

I'm not sure that os.urandom() is correct on OpenBSD. I'm not sure that using 
getentropy() is correct. getentropy() seems to be high quality but I understand 
that there is a low quantity of entropy and it can block.

I don't know if arc4random() is better: it's no more RC4 on recent OpenBSD, and 
it has an efficient implementation.

--
status: pending -> open

___
Python tracker 

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

[issue22542] Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present

[Nick Coghlan]

Nick Coghlan added the comment:

Victor, can this be closed following the changes to os.urandom() in 3.5 and 3.6 
to avoid using a file descriptor in os.urandom() where feasible?

--
nosy: +ncoghlan
status: open -> pending

___
Python tracker 

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

[issue22542] Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present

[700eb415]

700eb415 added the comment:

From the OpenBSD random(4) man page:
The arc4random(3) function in userland libraries should be used instead, as it 
works without the need to access these devices every time.

Theo just had a good talk on this issue here about why /dev/random needs 
replacing here: 
http://www.openbsd.org/papers/hackfest2014-arc4random/index.html . There's also 
a videon on YouTube.

At this point, I should probably have a patch ready sometime towards the middle 
of the week. I had a conversation with Ted Unangst off list, and think the best 
place for me to push it would first be a patch to the OpenBSD ports. After the 
OpenBSD guys review it, I'll then push it here.

--

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

[issue22542] Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present

[STINNER Victor]

STINNER Victor added the comment:

The issue is about the base if /dev/urandom is not present. How is 
arc4random() PRNG/CPRNG initialized if /dev/urandom is *not* present?

Can we rely on it if it only uses a poor seed?

--

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

[issue22542] Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present

[700eb415]

700eb415 added the comment:

 I'm not sure that arc4random() can be considered as coming from the OS.

We really have a couple options here. (1)Include a high quality pseudorandom 
number function for every platform that doesn't provide the proper call (very 
tedious and lots of places of mistakes - see: OpenSSL failing at this 
horribly), (2)get the OS venders to fix their software (not likely on this 
timescale), (3)use lots of #ifdef's to do platform detection (yuck), or 
(4)ignore broken calls provided by the system in hopes that the developers fix 
the issue.

Bob beck has a nice dialog on this problem in FreeBSD here: 
https://github.com/libressl-portable/portable/issues/17

It's ugly, but I'm leaning towards an #ifdef __OpenBSD__ in this case since 
it seems to be the only platform at this time with a sane implementation other 
than the latest Linux kernel.

 If you really want arc4random(), IMO you should add a *new* function, but it 
 would not be portable: only available on OpenBSD (and maybe other BSD 
 including Mac OS X), not available on Windows nor Linux. I'm not sure that it 
 fits Python portability policy, even if we have many functions which are only 
 available on some recent platforms, like many Linux-specific functions (in 
 the os module).

I think this would be a bad idea based on how easy this is to get wrong. The 
logic:

if /dev/urandom
...
else if os_has_proper_rand()
...
else
fail

seems to be the best way to handle this IMO until OS venders provide viable 
fixes.


Alternatively if the consensus is to reconvene at a later time, I could work on 
a patch for the OpenBSD port and we can ignore the problem here for now. 
However, I think the Python community is a great place to bring this issue to 
light much as was done with LibreSSL.

--

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

[issue22542] Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present

[STINNER Victor]

Changes by STINNER Victor victor.stin...@gmail.com:


--
title: Use arc4random under OpenBSD for os.urandom() - Use arc4random under 
OpenBSD for os.urandom() if /dev/urandom is not present

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

[issue22542] Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present

[STINNER Victor]

STINNER Victor added the comment:

 title: Use syscall (eg. arc4random or getentropy) rather than /dev/urandom 
 when possible - Use arc4random under OpenBSD for os.urandom()

For the usage getentropy(), I created a dedicated issue: #22585.

 arc4random() should be avoided IMO, on many systems (including OS X) it 
 really is still arc4

RC4 has known weaknesses since 1995, the most severe was reported the last year:
https://en.wikipedia.org/wiki/RC4#Royal_Holloway_attack

http://www.theregister.co.uk/2013/11/14/ms_moves_off_rc4/
Microsoft, Cisco: RC4 encryption considered harmful, avoid at all costs
and
RC4 is broken in real-time by the ‪NSA‬ – stop using it.

FYI On OpenBSD 5.5 and newer, arc4random() now uses ChaCha20:
http://www.openbsd.org/cgi-bin/man.cgi?query=arc4randomsektion=3arch=manpath=OpenBSD+Current

If I understand correctly, arc4random() uses the ARC4 algorithm on all 
platforms except OpenBSD 5.5 and newer.

OpenBSD 5.6 with its getentropy() will be available when Python 3.5 will be 
released (PEP 478): OpenBSD 5.6 is scheduled for one month (november 2014), 
whereas Python 3.5 is scheduled for September 2015.

I don't think that we need to add a very specific code in Python 3.5 only for 
the exact platform OpenBSD 5.5, for a very specific case: chroot without 
/dev/urandom. What's the point of a chroot without /dev/urandom? Other 
applications will also have security issues if /dev/urandom is not available.

Current before of Python 3.5 if /dev/urandom is not available:

$ ~haypo/prog/python/default/python
Fatal Python error: Failed to open /dev/urandom
Abandon (core dumped)

The error is reported immediatly at startup. So you can immediatly detect the 
issue with your chroot.

I don't trust a function from the user space.

os.urandom() is documented as providing entropy from the OS:
Return a string of n random bytes suitable for cryptographic use. This 
function returns random bytes from an OS-specific randomness source.
https://docs.python.org/dev/library/os.html#os.urandom

I'm not sure that arc4random() can be considered as coming from the OS.

If you really want arc4random(), IMO you should add a *new* function, but it 
would not be portable: only available on OpenBSD (and maybe other BSD including 
Mac OS X), not available on Windows nor Linux. I'm not sure that it fits Python 
portability policy, even if we have many functions which are only available on 
some recent platforms, like many Linux-specific functions (in the os module).

--
nosy: +haypo

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

[issue22542] Use arc4random under OpenBSD for os.urandom() if /dev/urandom is not present

[STINNER Victor]

STINNER Victor added the comment:

 Hopefully this could then be used as a template for getrandom() when 
 implemented on Linux.

Sorry, what is getrandom()?

Linux 3.17 has a new getrandom() syscall, but the C API is not defined yet (see 
the issue #22181). OpenBSD 5.6 will have a getentropy() syscall and a 
gentropy() function in the C libray.

If if you are discussing about an hypothetical function in the C library, it's 
out of the scope if this bug tracker. Python don't call directly syscalls (ok, 
there is only one place in _posixsubprocess to avoid a race condition).

--

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