
Use system random generator in crypto - sr2
https://github.com/nodejs/node/issues/5798
======
tptacek
I'm not a fan of this genre of HN posts, where we're encouraged to read lurid
displays of (for lack of any better word, but without intending much value
judgement) ignorance about some highly technical issue.

It's clear the Node team members do not have an especially good grasp on the
problem here (you don't need to read all the way to the part where they talk
about mixing in getpid to come to that conclusion).

It's also a little clear to me that the blunt-force approach of patrolling
major open source projects for bad RNGs and demanding they replace them with
urandom is _unlikely to be productive_. It becomes clear pretty quickly in
this thread that the "no" votes have basically been cornered, message board
flamewar style, and can't reconsider without losing face.

At the core of this discussion is a misunderstanding of the fundamental
problem with elaborate CSPRNGs --- a misunderstanding the "urandom" votes here
don't do a very good job of clearing up.

Specifically: the problem isn't _having enough entropy_ ; a very small amount
of entropy can be cryptographically stretched into a practically unbounded
feed of random bits. The value of adding more entropy is future secrecy (in
effect: key rotation), which is a systems concern more than a cryptographic
concern.

Rather, the problem with elaborate CSPRNGs is _the handling of whatever
entropy you collect_ , be it a mere 256 bits or a continuous running feed of
userspace entropy. It's that concern that has repeatedly blown up crypto
programs, and it's that concern that motivates us to rely on the kernel's
systemwide random number generator rather than schemes like "egd", because the
kernel CSPRNG is simpler, is a dependency in all systems anyways, can make
promises about sharing that are hard for userspace programs to make, and can
extract promises from the hardware that are not made directly to userspace
programs.

------
cwmma
tl;dr is basically on one side a suggestion to move away from the prng
included in openssl because it could have bug, could be used wrong, and
doesn't add anything from a cryptographic perspective and instead directly use
the OS methods of generating randomness. There is then a lot of resistance to
this on the grounds that fixing these theoretical bugs could add real bugs and
considering how many OSs need to be supported this would trend towards rolling
one's own crypto which the maintainers do NOT want to do.

There is openness though towards bundling libsodium and using it to generate
randomness.

~~~
glandium
> move away from the prng included in openssl because it could have bug, could
> be used wrong, (...) and instead directly use the OS methods of generating
> randomness.

This could phrased as: move away from a prng that could have bugs, could be
used wrong and instead use a different prng that could have bugs and could be
used wrong. And each platform would use a different prng.

Put this way, it's not really enticing.

~~~
LgWoodenBadger
It's a move to eliminate a dependency that provides no extra security (and
likely weakens security).

The dependency they want to eliminate (OpenSSL) ALREADY relies on the
"different prng that could have bugs and could be used wrong."

The only thing they would gain is not having to handle platform-dependent
issues reading from system's prng (which is only really different on
Windows?).

------
Phithagoras
Blog post at [https://sockpuppet.org/blog/2014/02/25/safely-generate-
rando...](https://sockpuppet.org/blog/2014/02/25/safely-generate-random-
numbers/)

------
gumby
side question: any recommendations for a good, portable, linear prng in C++ we
can embed in some proprietary code? We are doing some simulations which we run
on multiple architectures and sometimes want to _re_ run with different input
parameters...and so want the same stream of "random" numbers for multiple
runs.

My understanding (perhaps wrong?) is that open openSSL prng is exponential.

~~~
wolf550e
"exponential" in what?

You can just encrypt a counter using AES or ChaCha ([1]) to produce 2^68
random bytes from 24 initial bytes. You can use HKDF to expand 16 bytes into
as many key+nonce pairs as you want, each producing 2^68 random bytes.

1 - use AES if your hardware has AESNI, my mobile i7 can do AES at 5GB/sec on
a single core

~~~
gumby
Thanks, this is a good idea.

We don't need fast, we need repeatable so that the same seed into the same
prng produces the same number on different machines (different CPUs, different
OSes) which is why we want to change from simply using the system facilities
as we do now. Yet the number of calls to rand() in each simulation is high
enough that we don't want to simply keep a large table of random numbers.

~~~
wolf550e
AES and ChaCha are very repeatable. :-)

They also happen to be fast.

