Hacker News Reader

Comment by niftich | Hacker News Reader

Some additional requests:

- Rust (no out-of-the-box crypto lib AFAIK)

- Erlang (ships-by-default 'crypto' uses openssl)

- Java 7 and below are, unfortunately, still in common use, despite being end-of-life. There is a config file to be edited, or a switch to be passed to the java executable to switch the RNG source away from /dev/random, the pre-8 SecureRandom default.

- Some obvious note about how client-side Javascript is a lost cause, in case anybody's tempted

View on HN

Rust has no out of the box crypto, specifically because we want to take our time and get it right. The rand crate can generate random numbers, the ring crate is the most promising crypto library overall, IMHO.

In Rust, use the `rand` crate, with the `OsRng` random number generator.

https://docs.rs/rand/0.3.14/rand/#cryptographic-security

> Some obvious note about how client-side Javascript is a lost cause, in case anybody's tempted

Relevant (from 2011): https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

Well, actually JavaScript now has secure random number generator. You can use window.crypto.getRandomValues().

Edit: note that I did not say that other points in that article are irrelevant.

I'm not sure your point about Java 7 is correct. The docs (http://docs.oracle.com/javase/7/docs/technotes/guides/securi...) state that it is a SHA1PRNG, seeded with "true random". So the first call may block if it goes to /dev/random on Linux, but it should be good-to-go after that. I think this is the same behaviour as Java 6, but I don't know about previous versions.

Java 8 does define more sources for SecureRandom, including NativePRNGNonBlocking, which specifically refers to /dev/urandom (http://docs.oracle.com/javase/8/docs/technotes/guides/securi...).

Rust:

https://gist.github.com/jamwt/60f66f0fd27d349fe460051e55e79a...

(Also submitted to blog author.)

> Some obvious note about how client-side Javascript is a lost cause, in case anybody's tempted

crypto.getRandomBytes is supported by everything that matters[0], won't be a problem in ~5 years.

0: http://caniuse.com/#feat=getrandomvalues

If on Linux it's almost always safe to read from /dev/urandom.

> it's almost always safe

When is it not?

If you have a fresh VM without a seed file, that isn't connected to the internet and has had little in the way of devices, and you immediately begin generating keys before the normal file system operations stir the generator, then the deterministic nature of the generator says you'll get a predictable key, or more likely, end up generating a key that's simply not unique.

Just by being online and running for a few seconds will cause enough entropy to put the generator into a safe state, so this rarely happens in practice.

In fact Ubuntu comes prepackaged with pollinate[0] which makes this basically a non-issue for everyone that's not wearing a tinfoil hat.

1. http://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1....

Interesting. I get part of it. How does being online increase entropy?

Device interrupts will feed the generator so that the output from the CSPRNG is indistinguishable from random.

There's lots of stuff happening on a network that's impossible to guess and replay. This is also called noise.

Keep in mind that the CSPRNG generator only needs a random seed, then it can produce psuedo random numbers all day long. Linux will continue to reseed as more interrupts occur.

Linux will also save a 512 byte file on shutdown and seed the generator with it on the next boot up, so you immediately enter into a safe/random state.

Thanks for all the answers.

I can't repond directly to you. Device interrupts will feed the generator so that the output from the CSPRNG is indistinguishable from random.

There's lots of stuff happening on a network that's impossible to guess and replay.

Reply on news.ycombinator.com