4 ms·

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

by niftich 10y ago

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

indolering 10y ago
> 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 http://caniuse.com/#feat=getrandomvalues
matt_wulfeck 10y ago
If on Linux it's almost always safe to read from /dev/urandom.
- vram22 10y ago
  > it's almost always safe When is it not?
  - matt_wulfeck 10y ago
    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.html http://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1....
    - vram22 10y ago
      Interesting. I get part of it. How does being online increase entropy?
      - matt_wulfeck 10y ago
        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.
        vram22 10y ago
        Thanks for all the answers.
    - matt_wulfeck 10y ago
      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.
steveklabnik 10y ago
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.
ilyanep 10y ago
> 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/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
- eveningcoffee 10y ago
  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.
chrismorgan 10y ago
In Rust, use the `rand` crate, with the `OsRng` random number generator. https://docs.rs/rand/0.3.14/rand/#cryptographic-security https://docs.rs/rand/0.3.14/rand/#cryptographic-security
jamwt 10y ago
Rust: https://gist.github.com/jamwt/60f66f0fd27d349fe460051e55e79ac9 https://gist.github.com/jamwt/60f66f0fd27d349fe460051e55e79a... (Also submitted to blog author.)
Tinned_Tuna 10y ago
I'm not sure your point about Java 7 is correct. The docs (http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SecureRandom 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/security/StandardNames.html#SecureRandom http://docs.oracle.com/javase/8/docs/technotes/guides/securi...).

by niftich 10y ago

indolering 10y ago

> 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 http://caniuse.com/#feat=getrandomvalues

matt_wulfeck 10y ago

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

vram22 10y ago
> it's almost always safe When is it not?
- matt_wulfeck 10y ago
  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.html http://manpages.ubuntu.com/manpages/trusty/man1/pollinate.1....
  - vram22 10y ago
    Interesting. I get part of it. How does being online increase entropy?
    - matt_wulfeck 10y ago
      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.
      - vram22 10y ago
        Thanks for all the answers.
  - matt_wulfeck 10y ago
    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.

steveklabnik 10y ago

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.

ilyanep 10y ago

> 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/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

eveningcoffee 10y ago
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.

chrismorgan 10y ago

In Rust, use the `rand` crate, with the `OsRng` random number generator. https://docs.rs/rand/0.3.14/rand/#cryptographic-security https://docs.rs/rand/0.3.14/rand/#cryptographic-security

jamwt 10y ago

Rust: https://gist.github.com/jamwt/60f66f0fd27d349fe460051e55e79ac9 https://gist.github.com/jamwt/60f66f0fd27d349fe460051e55e79a... (Also submitted to blog author.)

Tinned_Tuna 10y ago

I'm not sure your point about Java 7 is correct. The docs (http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SecureRandom 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/security/StandardNames.html#SecureRandom http://docs.oracle.com/javase/8/docs/technotes/guides/securi...).