Author vstinner
Recipients 700eb415, alex, rpointel, vstinner
Date 2014-10-09.09:43:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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:
"Microsoft, Cisco: RC4 encryption considered harmful, avoid at all costs"
"RC4 is broken in real-time by the ‪NSA‬ – stop using it."

FYI On OpenBSD 5.5 and newer, arc4random() now uses ChaCha20:

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

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).
Date User Action Args
2014-10-09 09:43:58vstinnersetrecipients: + vstinner, alex, rpointel, 700eb415
2014-10-09 09:43:58vstinnersetmessageid: <>
2014-10-09 09:43:58vstinnerlinkissue22542 messages
2014-10-09 09:43:57vstinnercreate