Skip to content

crypto/rand: probably time to block in getrandom #19274

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
agl opened this issue Feb 24, 2017 · 4 comments
Closed

crypto/rand: probably time to block in getrandom #19274

agl opened this issue Feb 24, 2017 · 4 comments
Milestone

Comments

@agl
Copy link
Contributor

agl commented Feb 24, 2017

The 1.9 cycle might be the correct time to revisit #11833 now that getrandom has spread further, including into a Ubuntu LTS release.

@agl agl self-assigned this Feb 24, 2017
@bradfitz bradfitz changed the title Probably time to block in getrandom crypto/rand: probably time to block in getrandom Feb 24, 2017
@ianlancetaylor ianlancetaylor added this to the Go1.9 milestone Feb 24, 2017
@josephlr
Copy link
Member

Some more info here.

  1. Patch submitted to x/sys/unix to add in the more recent syscalls and add bindings for getrandom(). This might allow cleanup of the internal/syscall/unix and rand_linux.go code.

  2. According to this search on distrowatch.com, all of the 10 most popular distros + Arch Linux have releases with a new enough kernel to support this. As @agl mentioned, this includes Ubuntu 16.04 LTS, but also the LTS distros of Mint 17.3 (Rosa), Mint 18.1 (Serena), Fedora 21 and Later, and Manjoro 15-16. The big one missing is Debian which doesn't support it in 8 but will in 9 (which uses the 4.9 kernel) which will be out by Go 1.9.

  3. Finally, should the new implementation block or fail when the appropriate read cannot be done? Failing seems to fit the go paradigm the best as all readers can return an error. However, there is also the danger that not checking for the returned error can lead to a buffer that has some zero bytes still in it, so blocking might be the safer option.

@bradfitz
Copy link
Contributor

@agl, please do this this week if you want to get this in for Go 1.9.

@agl
Copy link
Contributor Author

agl commented May 22, 2017

(No chance at the moment because of <Google-internal reason that you might be aware of>.)

@gopherbot
Copy link
Contributor

CL https://golang.org/cl/43852 mentions this issue.

josephlr added a commit to google/fscrypt that referenced this issue Jul 12, 2017
This commit adds in RandReader, a cryptographically secure io.Reader
that will fail when the os has insufficient randomness. This is done
using the getrandom() syscall in non-blocking mode.
  see: http://man7.org/linux/man-pages/man2/getrandom.2.html
Any kernel new enough to have filesystem encryption will also have this
syscall.

This RandReader is preferable to the one provided by the standard
library in crypto/rand. See the bugs:
	golang/go#11833
	golang/go#19274
This will be removed when go updates the crypto/rand implementation.

Change-Id: Icccaf07bc6011b95cd31a5c268e7486807dcffe2
@golang golang locked and limited conversation to collaborators May 23, 2018
@rsc rsc unassigned agl Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants