Re: Cryptokit.Random unsuitable in cooperative multithreaded systems

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Mirage is just a collection of libraries, so we need to split up random number 
usage into a few scenarios:

- Cryptokit requires strong random numbers for key generation, so it uses 
/dev/random in UNIX and blocks.  Key generation is probably the only case where 
we want to use this.

- Other applications just want good-enough random sources, so in UNIX/Mirage we 
would use /dev/urandom, and in Xen/Mirage we would need an arc4random stirring 
pool and scavenge whatever we can get from the PV interfaces.

It's not clear to me what the best strategy is for key generation in Xen at the 
moment.  It does make me wonder if it's worth generating a bunch of SSH keys on 
Amazon EC2 and inspect their quality (although presumably, SSH uses /dev/random 
for this and should just be slow about key generation on Xen).  The latest Ivy 
Bridge chipsets do have hardware RNGs that should show up in a PV guest too.

-anil

On 24 Apr 2013, at 18:49, Stephen Dolan <stedolan@xxxxxxxxxxxx> wrote:

> Shouldn't Mirage be using /dev/urandom anyway? I don't think /dev/random is a 
> good idea for anything non-interactive, it's too easy to DoS.
> 
> Stephen
> 
> 
> On Wed, Apr 24, 2013 at 6:34 PM, Daniel Bünzli <daniel.buenzli@xxxxxxxxxxxx> 
> wrote:
> 
> 
> Le mardi, 23 avril 2013 à 15:28, Anil Madhavapeddy a écrit :
> 
> > Cryptokit's a pretty important project, particularly to Mirage. If I 
> > remember right, it moved to the Forge after Sylvain took over 
> > maintainership. The last release was June 2012, so it doesn't seem totally 
> > unmaintained.
> 
> Well the original author seems even active at the moment:
> 
> https://forge.ocamlcore.org/forum/forum.php?forum_id=875
> 
> Daniel
> 
>