It is easy to be a central source for randomness. The problem is that,
   for crypto, you want secret and private randomness.

   Whether it is reasonable to use randomness from an outside source to
   supplement the entropy on your own system depends on your threat model.

   If you absolutely require true randomness, and you are entropy
   constrained on the local device, and you are not concerned about
   compromise of the entropy server or the path between you and that
   server, then this might make sense.

   Lots of "ifs".

   -Lance

   --
   Lance Cottrell
   [1]loki@obscura.com
   On Jul 30, 2013, at 10:28 AM, Jon Callas <[2]jon@callas.org> wrote:

   On Jul 24, 2013, at 10:45 PM, Yan Zhu <[3]yan@mit.edu> wrote:

     Has anyone tried using an entropy broker (see
     [4]https://lwn.net/Articles/546428/) for sharing entropy between
     devices on a physical network?
     [5]https://we.riseup.net/debian/entropy#entropy-key seems to suggest
     that this is something that people do.

   Some time ago, I ended up being a mentor in some coding thing.
   Vagueness is there to protect the guilty.
   The project in question was for some program to communicate using
   one-time pads. That the pad in a one-time-pad must be full-entropy is
   why it's relevant. The question came up of how you distribute the pads,
   because that's the key problem (nyuck, nyuck) in doing a one-time-pad
   system.
   The solution the person came up with was to encrypt them with PGP using
   a 4K-bit RSA key. I leave commentary on this system to the reader, and
   won't spoil the thought experiment with my own, at the moment.
   This entropy broker strikes me as exactly the same sort of
   understanding.
   Jon

References

   1. mailto:loki@obscura.com
   2. mailto:jon@callas.org
   3. mailto:yan@mit.edu
   4. https://lwn.net/Articles/546428/
   5. https://we.riseup.net/debian/entropy#entropy-key