-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
proposal: math/rand/v2: add Rand.Read #65562
Comments
Not really about the proposal per se, but another reason not to add package-level Read is that nothing actually constrains those functions to use a CSPRNG. The fact that they use ChaCha8 is an implementation detail, and other Go implementations could make other choices. (E.g., TinyGo still uses xorshift in some cases.) We could promise to use a CSPRNG for package-level Read, but that's already what crypto/rand does. |
Will close this as a duplicate of #67059. |
This proposal is a duplicate of a previously discussed proposal, as noted above, |
Proposal Details
In #61716, Russ said:
I would like to formally propose this. To put it bluntly, I do not believe there is a meaningful security difference between reading from
crypto/rand
and reading from a ChaCha8 CSPRNG seeded fromcrypto/rand
. But others may disagree, and if adding a top-levelRead
causes tools likegoimports
to importmath/v2/rand
instead ofcrypto/rand
, they could rightfully complain. Thus I propose addingRand.Read
, but not a top-levelRead
.The text was updated successfully, but these errors were encountered: