[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cryptokit.Random unsuitable in cooperative multithreaded systems

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.


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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.