Expose Both /dev/random & /dev/urandom

[nixpulvis]

I think it would be ideal to support a blocking and non-blocking interface, and allow users to make use of /dev/random as well. I’m not by any means an expert, but common sense tells me that /dev/random should be strictly better than /dev/urandom in the general case.

[nixpulvis]

Just found ReadRng, so this is obviouly possible, maybe im just wanting a closer mapping to the Linux API, which may be the wrong idea. Sorry if this feels like bikeshedding now.

[nixpulvis]

Maybe the best way to read this is within the context of OsRng.

[nixpulvis]

I’ll be honest, the discussion on https://www.python.org/dev/peps/pep-0524/ didn’t seem very safisfying.

[dhardy]

Common sense doesn't get you very far in cryptography (without a lot of questioning). Certainly /dev/random should not be worse than /dev/urandom, but it only has better security if an attacker somehow compromises the kernel entropy (but then you shouldn't trust /dev/random either) or if someone discovers a serious weakness in the CSPRNG algorithm (but then a lot of crypto could would be vulnerable — ChaCha20 is widely used). The general advise is just to use /dev/urandom. To quote the man page:

If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter. As a general rule, /dev/urandom should be used for every‐thing except long-lived GPG/SSL/SSH keys.

That said, /dev/random is still available for use. OsRng is designed for general-purpose cross-platform usage however. I doubt many users really need /dev/random so I'd suggest just using ReadRng::new(File::open("/dev/random")).

[nixpulvis]

Fair enough. Though a question still remains if it makes sense to support both a synchronous and async interface. Right?

[dhardy]

There was some discussion of this in error kinds: hence ErrorKind::NotReady (see #9). But this interface only works with a function returning errors like try_fill.

[dhardy]

Without any listed rationale / use-case, and since the current design partly covers the requirements here, I'm going to close this. If you still want extra functionality you're going to have to be more specific, and provide good motivation (because the API is already much more complex than I'd like).