proposal: math/rand: disambiguate Read from crypto/rand.Read

[jondb]

What version of Go are you using (go version)?

1.7.3

What operating system and processor architecture are you using (go env)?

all

What did you do?

I wrote https://play.golang.org/p/WpSHEv_Mc7

import "math/rand"
_, err := rand.Read(randBuff)

I should have written https://play.golang.org/p/Ho8Ior-om7

import "crypto/rand"
_, err := rand.Read(randBuff)

In practice, the import statement and the function invocation are not one line apart, but separated by a lot of code. Also, IDEs may automatically import the wrong package.

What did you expect to see?

I expected crypto rand to be obviously different than math rand. Something like:

import "crypto/rand"
_, err := rand.CryptoRand(randBuff)

while,

import "math/rand"
_, err := rand.InsecureRand(randBuff)

This makes it super clear that one is not like the other, and helps the developer decide which to use. Also helps code reviewers determine if there is an obvious error.

Security should be explicit.

What did you see instead?

I saw experienced and inexperienced developers both make the same mistake of using math/rand instead of crypto/rand, and code reviews miss the problem.

[bradfitz]

We can't change this for Go 1, so I've tagged this for Go2 for consideration in the future.

[randall77]

You can always do

import crytporand "crypto/rand"
cryptorand.Read(randBuff)

That at least makes it clearer at the callsite what you intended.

[jondb]

@bradfitz - makes sense; is there a warning capability in the Go 1 compiler?
@randall77 - designing things to be secure by default is the principle here. Your suggestion might work with a lint system to produce a warning when using math.rand.

[bradfitz]

makes sense; is there a warning capability in the Go 1 compiler?

Intentionally not. See the https://golang.org/doc/faq#unused_variables_and_imports answer.

[AlexRouSg]

Why can't we just add new alias functions with a suffix like Crypto e.g. ReadCrypto/NewCrypto/NewSourceCrypto/etc...

That way we still have the 1.0 compatibility and makes it easier for people to make sure they are using the correct rand.

[bradfitz]

I suppose we could, but we generally try to avoid having two ways to do the same thing.

[AlexRouSg]

Well I'm not in the affected group so I'll let you guys debate if the pros outweigh the cons.

But I can imagine some company having a security vulnerability cause of some late night coding where someone auto imported math/rand instead of crypto/rand.

[bradfitz]

Your security vulnerability scenario involves all of the following failures:

• a tool automatically chose math/rand instead of crypto/rand. goimports doesn't do this as of a year ago. That was fixed in golang/tools@0835c73
• somebody wrote security code late at night
• code review didn't happen or missed the problem

It's possible, but it's a bit of a stretch. I don't think it warrants fixing in Go 1.x where it can't be changed cleanly.

In the meantime, file bugs against any auto-import tools that get it wrong.

[ericlagergren]

Also: tools like gas (https://github.com/GoASTScanner/gas) already catch this.

[ianlancetaylor]

I don't think we should change the name of the Read function, but for Go 2 we could perhaps change the name of the type crypto/rand package to, perhaps, crypto/crand, to decrease the chance of accidental confusion.