[ruby-core:76034] [Ruby trunk Bug#9569] SecureRandom should try /dev/urandom first
From:
azet@...
Date:
2016-06-15 13:27:34 UTC
List:
ruby-core #76034
Issue #9569 has been updated by Aaron Zauner.
Yui NARUSE wrote:
> Shyouhei Urabe wrote:
> > @naruse Do you think it's inadequate for Linux users to fall back to getrandom(2)? If so, why?
>
> getrandom has some limitations like its max output (33554431), and consumes entropy.
>
>
> Anyway I'm creating a securerandom.gem which uses arc4random_buf internally like libressl RAND_bytes.
> https://github.com/nurse/securerandom
This uses `CryptGenRandom` on Windows (as does OpenSSL currently).
```
Historically, we always told developers not to use functions such as rand to generate keys, nonces and passwords, rather they should use functions like CryptGenRandom, which creates cryptographically secure random numbers. The problem with CryptGenRandom is you need to pull in CryptoAPI (CryptAcquireContext and such) which is fine if you’re using other crypto functions.
On a default Windows XP and later install, CryptGenRandom calls into a function named ADVAPI32!RtlGenRandom, which does not require you load all the CryptAPI stuff. In fact, the new Whidbey CRT function, rand_s calls RtlGenRandom.
The following snippet shows how to call the function.
HMODULE hLib=LoadLibrary(“ADVAPI32.DLL”);
if (hLib) {
BOOLEAN (APIENTRY *pfn)(void*, ULONG) =
(BOOLEAN (APIENTRY *)(void*,ULONG))GetProcAddress(hLib,”SystemFunction036″);
if (pfn) {
char buff[32];
ULONG ulCbBuff = sizeof(buff);
if(pfn(buff,ulCbBuff)) {
// use buff full of random goop
}
}
FreeLibrary(hLib);
}
The good news is you can get good random numbers, without the memory overhead of pulling in all of CryptoAPI!
RtlGenRandom is documented at http://msdn.microsoft.com/library/en-us/seccrypto/security/rtlgenrandom.asp.
```
https://blogs.msdn.microsoft.com/michael_howard/2005/01/14/cryptographically-secure-random-number-on-windows-without-using-cryptoapi/
If you use API's like the one provided by `libsodium`/`NaCl` (called `sysrandom`) the this will be handled for you automatically. If things change in the OS, the library maintainers make sure to use the latest secure OS mechanisms and provide support for legacy systems.
----------------------------------------
Bug #9569: SecureRandom should try /dev/urandom first
https://bugs.ruby-lang.org/issues/9569#change-59235
* Author: Corey Csuhta
* Status: Open
* Priority: Normal
* Assignee:
* ruby -v:
* Backport:
----------------------------------------
Right now, `SecureRandom.random_bytes` tries to detect an OpenSSL to use before it tries to detect `/dev/urandom`. I think it should be the other way around. In both cases, you just need random bytes to unpack, so SecureRandom could skip the middleman (and [second point of failure](http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/)) and just talk to `/dev/urandom` directly if it's available.
Is this a case of just re-ordering the two code chunks so that `/dev/urandom` is tried first?
Relevant lines: https://github.com/ruby/ruby/blob/trunk/lib/securerandom.rb#L59-L90
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>