Closed lukechampine closed 2 months ago
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.
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, 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
.