3 ms·

This sort of code is one of the motivations behind improving the random number generation facilities available in C++. If you're using C++ or you're using C and

by sjolsen 12y ago

This sort of code is one of the motivations behind improving the random number generation facilities available in C++. If you're using C++ or you're using C and have the option to link with C++, I strongly recommend looking at the random number library introduced in C++11 [1]. In addition to letting you specify a statistical distribution (including a proper uniform distribution for both integral and floating-point types), it lets you choose between various PRNG engines with various trade-offs. It also provides a way to source hardware entropy with which to seed an engine, and it's all pretty easy to use. *[1] en.cppreference.com/w/cpp/numeric

nepalisaathi 12y ago
Proper link en.cppreference.com/w/cpp/numeric
jacobparker 12y ago
Language lawyer note: std::random_device isn't guaranteed to be hardware-based, or anything in particular: http://en.cppreference.com/w/cpp/numeric/random/random_device http://en.cppreference.com/w/cpp/numeric/random/random_devic... (GNU libstdc++ will use rdrand if possible, otherwise it will read from /dev/urandom: https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libstdc%2B%2B-v3/src/c%2B%2B11/random.cc;hb=HEAD https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libstdc%2B...)
- sjolsen 12y ago
  You are correct; and of course, any hardware-level behaviour is likely to be implementation defined. I should note that MSVC [1] guarantees "non-deterministic and cryptographically secure" behaviour; and that libc++ [2] uses the "cryptographically secure" rand_s [3] on Windows, NaCl on other platforms where NaCl is available, and /dev/urandom where it isn't. [1] http://msdn.microsoft.com/en-us/library/bb982250.aspx http://msdn.microsoft.com/en-us/library/bb982250.aspx [2] https://github.com/llvm-mirror/libcxx/blob/master/src/random.cpp https://github.com/llvm-mirror/libcxx/blob/master/src/random... [3] http://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx http://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx
tptacek 12y ago
It's nice to make it clear what distribution you're going to get from a PRNG, or what the performance characteristics are going to be. But for cryptographic randomness (the subtext of 'tedunangst's post), what you don't want are a bunch of knobs and dials. What you generally need is a guarantee that your RNG interface is feeding you data from the system secure random number generator --- either urandom or CryptGenRandom. I'm also not sure what "hardware" has to do with that guarantee. One example I can think of where a standard library got this right is Golang: http://golang.org/pkg/crypto/rand/ http://golang.org/pkg/crypto/rand/
- pbsd 12y ago
  FWIW, the C++ random number library is very much not meant for cryptography. This is obvious when you see the weak guarantees given by std::random_device: on Windows, libstdc++ will actually use the Mersenne Twister with a hardcoded seed, and this is standard-compliant! Additionally, every engine included in the library is not cryptographic at all. The Boost random library actually does the right thing, and states that boost::random_device must not be implemented where a proper source of random bits is not available. The standard tries to be all things to all people, and std::random_device ends up being useless for any serious application. As a mathematical random number generation library, the C++ library is much superior to its Go counterpart, math/rand.
- sjolsen 12y ago
  > what you don't want are a bunch of knobs and dials. What you generally need is a guarantee that your RNG interface is feeding you data from the system secure random number generator The two are not necessarily incompatible. The distributions in the C++ standard library are not married to the standard engines. You can quite straightforwardly write an engine that uses urandom internally and which is compatible with the standard distributions; see the last couple dozen lines of libc++'s random.cpp. Now, whether there are instances where using a statistical adapter with cryptographically secure random numbers is appropriate is another question, and one which I am not qualified to answer. However, such adapters as std::uniform_int_distribution and std::independent_bits_engine, if it can be verified that they are implemented correctly (and that is admittedly a big "if"), would probably still be useful.

by sjolsen 12y ago

nepalisaathi 12y ago

Proper link en.cppreference.com/w/cpp/numeric

jacobparker 12y ago

Language lawyer note: std::random_device isn't guaranteed to be hardware-based, or anything in particular: http://en.cppreference.com/w/cpp/numeric/random/random_device http://en.cppreference.com/w/cpp/numeric/random/random_devic... (GNU libstdc++ will use rdrand if possible, otherwise it will read from /dev/urandom: https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libstdc%2B%2B-v3/src/c%2B%2B11/random.cc;hb=HEAD https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libstdc%2B...)

sjolsen 12y ago
You are correct; and of course, any hardware-level behaviour is likely to be implementation defined. I should note that MSVC [1] guarantees "non-deterministic and cryptographically secure" behaviour; and that libc++ [2] uses the "cryptographically secure" rand_s [3] on Windows, NaCl on other platforms where NaCl is available, and /dev/urandom where it isn't. [1] http://msdn.microsoft.com/en-us/library/bb982250.aspx http://msdn.microsoft.com/en-us/library/bb982250.aspx [2] https://github.com/llvm-mirror/libcxx/blob/master/src/random.cpp https://github.com/llvm-mirror/libcxx/blob/master/src/random... [3] http://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx http://msdn.microsoft.com/en-us/library/sxtz2fa8.aspx

tptacek 12y ago

It's nice to make it clear what distribution you're going to get from a PRNG, or what the performance characteristics are going to be. But for cryptographic randomness (the subtext of 'tedunangst's post), what you don't want are a bunch of knobs and dials. What you generally need is a guarantee that your RNG interface is feeding you data from the system secure random number generator --- either urandom or CryptGenRandom. I'm also not sure what "hardware" has to do with that guarantee. One example I can think of where a standard library got this right is Golang: http://golang.org/pkg/crypto/rand/ http://golang.org/pkg/crypto/rand/

pbsd 12y ago
FWIW, the C++ random number library is very much not meant for cryptography. This is obvious when you see the weak guarantees given by std::random_device: on Windows, libstdc++ will actually use the Mersenne Twister with a hardcoded seed, and this is standard-compliant! Additionally, every engine included in the library is not cryptographic at all. The Boost random library actually does the right thing, and states that boost::random_device must not be implemented where a proper source of random bits is not available. The standard tries to be all things to all people, and std::random_device ends up being useless for any serious application. As a mathematical random number generation library, the C++ library is much superior to its Go counterpart, math/rand.
sjolsen 12y ago
> what you don't want are a bunch of knobs and dials. What you generally need is a guarantee that your RNG interface is feeding you data from the system secure random number generator The two are not necessarily incompatible. The distributions in the C++ standard library are not married to the standard engines. You can quite straightforwardly write an engine that uses urandom internally and which is compatible with the standard distributions; see the last couple dozen lines of libc++'s random.cpp. Now, whether there are instances where using a statistical adapter with cryptographically secure random numbers is appropriate is another question, and one which I am not qualified to answer. However, such adapters as std::uniform_int_distribution and std::independent_bits_engine, if it can be verified that they are implemented correctly (and that is admittedly a big "if"), would probably still be useful.