Roll the dice, spin the roulette, or revolve the cylinder, always

When I posted a note at identi.ca, jwilkins kindly informed me the article by Dustin Kirkland: Improving Random Seeds in Ubuntu 14.04 LTS Cloud Instances

I am pleased to know there are other people who care.

While I think that the viewpoint of needs for entropy is same or similar, the fundamental philosophy seems differ somehow. In this memorandum, I try to write my idea or philosophy.

Extending /dev/random to the Net

The fundamental idea of Kun9BE4 is extending /dev/random (not /dev/urandom) to the distributed network. We prepare entropy for use and we deliver entropy through the distributed network. On each host, we have hardware random number generator (HWRNG) to collect entropy and we share (massive amount of) these devices among network. The rule is simple: when we use some entropy, then we need to collect another.

Seeding to PRNG

Seeding to PRNG is important. And it would be OK (practically) to keep using well-seeded PRNG for the duration, or it would be OK to keep using PRNG which is occasionally re-seeded.

I don't want to bet if it has decided in advance

Even though it would be OK to use only limited amount of entropy with PRNG for some duration. But it means that it is deterministic for the duration. For me, "determined in advance" sounds unfair or dishonesty.

It will be good if we can access full of entropy, always, and it is not determined in advance, by any means.

Our grass-root network again

I remember our modem, Trailbraizer, and the days of USENET in early 90's.

And I wish the random pool network can contribute to reset the network.

Encryption?

I don't think encryption makes much sense for packets in the network, since it is not the exact data itself each node wants.

If an admin of a node cares wire tap, having a filter before /dev/random is good. Such filter could be one of "Conditioning components" (with node specific secret key) defined in "6.4.2.1 Approved Keyed Conditioning Functions" in the document NIST DRAFT Special Publication 800-90B, titled Recommendation for the Entropy Sources Used for Random Bit Generation, by Elaine Barker and John Kelsey. This way, it's a kind of "decryption" by receiving node.

TCP?

My final target of the network is edge router integration. Like DHCP and DNS, it should be supported by each edge router. Resource requirement should be minimum so that router with 32MB memory could be no problem.

I think that UDP is more suitable for the protocol, as we don't need reliable stream.

OpenPGP or X.509

On the other hand, signature makes sense for packets in the network.

I'm considering using EdDSA signature, and OpenPGP to trust nodes.

Disclosure

My work place in Maebashi is next to "Green Dome Maebashi" where people come to bet on bicycle races. The title of this memorandum or content has no relation to "Green Dome Maebashi" and its activities. But when you want to visit Maebashi to see Green Dome, I'll be with you.