code review 569044: crypto/rand: new package

crypto/rand: new package

Until proven insufficient, rely on the operating system
to give us good random bytes (/dev/urandom).

[rsc, 2010-03-16 22:35:42]

Hello agl1 (cc: golang-dev@googlegroups.com),

I'd like you to review this change.

[agl1, 2010-03-16 22:52:35]

LGTM.

A couple of notes. With the addition of the Nanoseconds call, this might be
slower than /dev/urandom on 32-bit systems. (64-bit systems have VDSO, so it
might be ok there.)

Secondly, /dev/random blocks a lot and for an arbitrary amount of time. Either
it should see itself from /dev/urandom or there should be blazing huge warnings
to that effect in the comments.

[rsc, 2010-03-16 23:15:59]

> A couple of notes. With the addition of the Nanoseconds call, this might
> be slower than /dev/urandom on 32-bit systems. (64-bit systems have
> VDSO, so it might be ok there.)
>
> Secondly, /dev/random blocks a lot and for an arbitrary amount of time.
> Either it should see itself from /dev/urandom or there should be blazing
> huge warnings to that effect in the comments.

Is /dev/urandom reliable enough?  I'm happy to seed from or just
read directly from there, but I was also trying to do something that
had better worst case entropy than /dev/random.

What do other libraries do for the random bytes they need for,
say, key generation?

Russ

[agl1, 2010-03-17 01:17:34]

On Tue, Mar 16, 2010 at 7:15 PM, Russ Cox <rsc@golang.org> wrote:
> Is /dev/urandom reliable enough?  I'm happy to seed from or just
> read directly from there, but I was also trying to do something that
> had better worst case entropy than /dev/random.

/dev/urandom is pretty good.

> What do other libraries do for the random bytes they need for,
> say, key generation?

GPG maintains a random seed file in your home dir. If the seed is
exhausted it appears to use both /dev/random (to exhaustion) and
/dev/urandom. OpenSSL just uses /dev/urandom.

Non blocking is important enough that it should be an option, although
there are cases where /dev/random is warranted (like key gen).


AGL

[rsc, 2010-03-17 01:58:50]

Hello agl1 (cc: golang-dev@googlegroups.com),

Please take another look.

[agl1, 2010-03-17 02:20:09]

LGTM

[rsc, 2010-03-17 06:12:22]

*** Submitted as http://code.google.com/p/go/source/detail?r=c827563980e5 ***

crypto/rand: new package

Until proven insufficient, rely on the operating system
to give us good random bytes (/dev/urandom).

R=agl1
CC=golang-dev
http://codereview.appspot.com/569044