[MirageOS-devel] Update on entropy

[david <unitedbiscuits@xxxxxxxxx>]

Folks,

After yesterday's Mirage Call, Thomas G, Hannes and myself stared at a
whiteboard trying to figure out how to proceed on the entropy front,
prompted by [1] and the ensuing discussion.

As a little background, Nocrypto contains a piece of code capable of
accepting small bits of unpredictable information at irregular
intervals, and producing an unbounded stream of at least equally
unpredictable bytes on demand. This is Fortuna [2], Schneier's blessed
CSPRNG, and initially, it seemed like a good idea to decouple this
inherently deterministic algorithm from whatever serves to provide
bits of unpredictability and expect the latter part to be provided by
"the platform".

Attempts to endow the platform with this facility resulted in the
ENTROPY signature [3]. To avoid a general crypto library from
depending on a specific MirageOS sig, Nocrypto did nothing to hook
itself to this facility, which led to the problem of who gets to start
the entropy harvesting loop and connect it to the RNG, a bit of code
that started spilling around the ecosystem.

Now, taking a step back, it seems that the entire ENTROPY sig is
actually a bad idea. It could serve two purposes:

* any RNG can be fed through a standard mechanism of providing noise; and
* it is possible to independently create new sources of noise.

But it seems unlikely that anyone else will make another crypto-strong
RNG for MirageOS, given that the design space as described in the
current literature is not terribly large. On the other hand, we
already have implementations of various entropy sources in use by
equivalent systems (Xentropyd, RD{SEED,RAND}, inter-event cycle
counting, /dev/urandom), and it seems that allowing these sources to
be implemented and plugged-in independently provides little value.

Compounding the confusion, I think it is actually a very bad idea to
adopt the general MirageOS design in this instance, and allow the
application writer to statically describe their entropy sources
through module composition. This is because we have a nascent
fail-over logic which probes for available facilities and uses an
appropriate mix, because in general it is preferable to have *all of
them* anyway, and because leaving such a tricky decision to everyone
who wants to use, say, Conduit, reeks of poor API design.

So what we figured out would be the best way forward is:

* remove ENTROPY sig from Mirage types;
* add a RANDOM interface to Nocrypto so that, say, TCP can use Fortuna;
* extend this interface with a more general "start me now" entry-point
a little like `self_init`;
* fix the `mirage` tool to discover usage of a RANDOM implementation
and emit code to trigger this in the init preamble; and
* make the logic of probing for sources at boot-time, activating them
and connecting them to Fortuna [4] nocrypto-specific.

This effectively removes entropy from the MirageOS types ecosystem,
internalizes it into what realistically looks like its only client in
the forseeable future, and adds a minimal and general support for
RANDOM-like things to `mirage`-the-tool. The end result drops a bit of
flexibility and a lot of unclear design.

And the question I am raising is: Are there objections to this? Did
anyone want to code something that requires direct access to entropy
sources (i.e. another RNG)? Did anyone want to make a separate entropy
provider?


Cheers,
David


[1] - https://github.com/mirage/mirage/pull/390
[2] - https://www.schneier.com/fortuna.html
[3] - https://github.com/mirage/mirage/blob/master/types/V1.mli#L80
[4] - 
https://github.com/pqwy/mirage-entropy/blob/f0935a329502e76f92133805c7d40da92ec42fe8/xen/entropy_xen.ml#L153

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel