Re: Cryptokit.Random unsuitable in cooperative multithreaded systems

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 23 Apr 2013, at 14:58, David Sheets <sheets@xxxxxxxxxxxx> wrote:

> Cryptokit.Random.secure_rng might use /dev/random for entropy
> generation which might block if there isn't enough available entropy.
> My local machine never seems to have low entropy with
> 
> $ cat /proc/sys/kernel/random/
> entropy_avail
> 3480
> 
> but ocaml-www2 says
> 
> $ cat /proc/sys/kernel/random/entropy_avail
> 147
> 
> There are only a handful of Unix calls in the library...

ocaml-www2 is a Xen VM, and so the low amount of entropy is to be expected.
(whatever happened to the PV Randfront and Randback, Dave?  There was some
concern that it was hard to schedule this with a client that could consume
all of dom0's pool, but I suggested using arc4random_stir in the backend to
alleviate that... back in 2006 iirc).

However, we could write a simple Lwt_random wrapper module that puts
/dev/random into non-blocking mode and adds it to the select loop.  You'll
need to verify that a non-blocking /dev/random doesn't just fallback to the
/dev/urandom behaviour though!  I've never actually tried to access the
random interface with async code, and wouldn't be surprised if something
non-portable and surprising happens here.

> Additionally, Vincent Bernardoff appears to have forked Cryptokit with
> the unmerged addition of SHA-512 
> <https://github.com/vbmithr/cryptokit-sha512>.
> 
> What's the status of this library? Is it part of Mirage? Are we
> forking it? Is it maintained?

We'll need a short-term Mirage fork to separate out the C bindings, but
should feed it back upstream in the long term.  Vincent, I'll leave the SHA256
question to you.

> I'm using Random for now as it doesn't really matter to have secure
> RNG for ocamlot.

Yeah, that's fine.

-anil