You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we do keep ChaCha8 as the global generator and commit to having some cryptographic global generator like ChaCha8 in the future, we could potentially bring back both the top-level Read function and the Rand.Read method.
In the earlier discussion, some people asked what to do about getting short byte sequences from the PRNG. We essentially sacrificed the convenience of Read for the security of forcing people over to crypto/rand. But if we make the top-level Read backed by a cryptographic generator, we could bring Read back and have both convenience and security.
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 from crypto/rand. But others may disagree, and if adding a top-level Read causes tools like goimports to import math/v2/rand instead of crypto/rand, they could rightfully complain. Thus I propose adding Rand.Read, but not a top-level Read.
The text was updated successfully, but these errors were encountered:
I do not believe there is a meaningful security difference between reading from crypto/rand and reading from a ChaCha8 CSPRNG seeded from crypto/rand. But others may disagree, and if adding a top-level Read causes tools like goimports to import math/v2/rand instead of crypto/rand, they could rightfully complain.
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.
This proposal is a duplicate of a previously discussed proposal, as noted above,
and there is no significant new information to justify reopening the discussion.
The issue has therefore been declined as a duplicate.
— rsc for the proposal review group
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: