Re: [MirageOS-devel] Update on entropy

[david <unitedbiscuits@xxxxxxxxx>]

Hey all,

I wrote up the current state in an issue on github:
https://github.com/mirleft/ocaml-nocrypto/issues/55 .

I would appreciate any feedback on it, before moving to merge it all.


On Tue, Mar 31, 2015 at 4:41 PM, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA384
>
> Hi,
>
> I do like the proposed changes.  My intuition is that the mirage tool
> knows whether nocrypto is used or not (and thus, emits a call to
> rng_init before calling main -- it should as well call self_init on
> the Random-based RANDOM device, thus the TCP/IP stack doesn't have to
> https://github.com/mirage/mirage-tcpip/blob/78124d5eb3095a7cf516d54ca4929ff69a2ce89b/tcp/pcb.ml#L574).
>  Based on the same check, the TCP stack could also use the Nocrypto
> RANDOM device.
>
> What is crucial here, is that we have a good entropy story on all of
> the possible deployment scenarios (and furthermore a way to find out
> which entropy sources are mixed in):
> - - Xen + ARM: xentropyd (for now), soon cycle counters
> - - Xen + X86 (control over dom0): RDSEED/RTDSCP / xentropyd
> - - Xen + X86 (ec2): RDSEED/RTDSCP
> - - Unix: /dev/urandom
>
> Viewed in a different angle: for each deployment scenario we need a
> good story for continuous entropy sources.
>
> The RANDOM device should include a
> `entropy_source : entropy_source list`
> with
> `type entropy_source = [ `RDSEED | `RDRAND | `Xentropyd | `Urandom ]`
>
> Thus, a unikernel could exit early if its favorite (or expected)
> entropy source(s) is(are) not present.
>
> Developers should not have to decide which entropy sources to mix in,
> but a paranoidic user might want to compile their entropy source
> package without rdseed support:  Entropy sources are selected at
> runtime from the compiled-in ones (you can manually patch/configure
> your entropy source package)!
>
> Which opens the question where to keep the entropy source
> implementations and which interface do they need to fulfill?  I
> suspect mirage-entropy is a good place to keep them, and do the
> runtime detection and mixing logic in there.  Certainly for use cases
> without mirage, the direct /dev/urandom feeder should life somewhere
> else, maybe in nocrypto.lwt (currently both mirage-entropy-unix and
> tls.lwt contain those bits, but certainly I'd like to use Fortuna
> without TLS!)?
>
>
> These changes will also simplify the Tls_mirage interface, which does
> not need to be functorized over a ENTROPY device.  (Also, TLS won't be
> able to use the abstract RANDOM device because it needs a much richer
> API.  I don't think there's much value in extracting this richer API
> into mirage-types, which would then need to depend on e.g. Z(arith).)
>
>
> hannes
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCQAGBQJVGsBGAAoJELyJZYjffCjupHUP/0UlyTHcMxNzHo3jQdAEvh1Z
> MayhrDomQHmOJMteLLROQ/v3b7tM2xJS2+yiqJIE793aYcfEqWGzxheePW3hwLVV
> 9OPCzQ19WSYEJg5MRAoEa/Q/umUrEoroDOoGWLj1lpiSkE8Y/N6pXuaE+SisYXjn
> 8+Gx/HrCj8CL3zp4XWJfA+QRjvX6jKVvmUgeuqaVemdsXYWTn7eTPZ3vCUtm9t0U
> SPSB92B5sF+YWA0abSJq4CQzWOlQEuBTVm6I7i8m5UMWYxgiu/9ZkDktUkKhnkao
> vD47WpzRasHaKtk2xn1nwE6+BH37zLvJc6wtCqTnu1UB/2FQwk4uuFqlbKeKEKNd
> c1CKSuwcAxvIW69rhvyDEwJnudQwy8y8x5560FBWqG6bkBb0wt0qspljDmERB5Vi
> oEsupfH8FVl2aLQWI/HCfAc7Jp+O5OFYykAxR3sFUpC4AWle808SsUbACtUEzhzN
> gSV8lBoDN11NWxlgOvv2eeqsyJGqzD+koOhVxPqjooejRsGbOTA7Bgu/kA/ZMQE9
> uShEN1QK8mJXvEeOzr/4UF+QVq9curfJP969YBxeww5dw4MgV1GhoovcDU5il+7g
> FsacQO546tEevk9tOFYBYsGhi7hwYkjzl0sVYuBO5gPvVD2hQkkXMpErYYRCZPlq
> 3JcAXvo57Nt44aUadHT7
> =2E3I
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel



-- 
"Linear Time is wrong and suicidal." -- Gene Ray

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