I would add to that, I just realized there's a few potential problems, such as:
I spam your listener with packets until your RNG produces values with some bits that I like. Similar to RDRAND firmware problem. The problem here is that I can convince you to add crud to your pool, and even though that only randomly controls it.... could be solved by adding entropy only when you want it. I guess. Needs thought. Potential interesting question is to keep the channel silent until someone "asks" for entropy with a subnet-directed broadcast? So basically a request/response protocol, only shared. Another question is "do your broadcasts of RNG state reveal too much about your pool state". I'm guessing the answer is no but if not you can always encrypt or HMAC with one key before broadcast, and another before local use... I tend to think of these like diodes, where it prevents inferring the value on the side of the diode that doesn't have the key, and the hash-based one additionally does not allow inference from output to input. Thus I can encrypt on arrival with a local key and the person who fed it to me has no information about what I obtained from it, but I know what they gave me (which is sort of unavoidable). Conversely I can HMAC on output and you don't know what I started with, for two reasons - no key and the OWF. The two combined act as e.g. optoisolators on input and output. -- http://www.subspacefield.org/~travis/ "Computer crime, the glamor crime of the 1970s, will become in the 1980s one of the greatest sources of preventable business loss." John M. Carroll, "Computer Security", first edition cover flap, 1977
pgp73tpOHOYnl.pgp
Description: PGP signature
_______________________________________________ RNG mailing list [email protected] https://lists.bitrot.info/mailman/listinfo/rng
