"Travis H." <[EMAIL PROTECTED]> writes: > That leaves me with the following design: > > That random numbers be sent en clair from the system that can generate > them to the system that needs them, where they are decrypted using a > random key (generated locally by /dev/random) and fed into the system > that needs them, in this case the pool used by /dev/random (where they > will be hashed together with interrupt timings and other complex > phenomena before being used). > > If the attacker has no access to the LAN traffic, then it gives the > benefit of a local HWRNG. If the attacker has access to all the > network traffic and a great deal of the output of /dev/random on the > receiving machine, he has at best, a "ciphertext" and the hash of the > (completely random) "plaintext" to work with. In actuality it is > liable to be less clear than that, as /dev/random will scramble it > with a bunch of low-level stuff and give the hash of that. State > remains in the /dev/random pool, so that the next transmission will be > mixed with the pool created by the first transmission and so on. So > in practice an attacker wouldn't even have the hash of the plaintext. > > Does anyone see any problem with the reasoning or resultant design? > I'd prefer to not argue over the assumptions. Does anyone have any > ideas about how to handle authentication/integrity?
Look, this design just reduces to a standard cryptographic PRNG with some of the seed being random and periodically being reseeded by the "random" network stream you're sending around. There's no need to worry about the integrity or confidentiality of the "random" stream because anyone who controls the network already knows this input. The only information they don't have is your "random" private key. That said, frankly, this is all rather silly. A good cryptographic PRNG seeded with a few hundred bytes of high-quality randomness is good enough for bits of randomness is good enough for practically any purpose. Practically the only thing it's not useful for is for generating OTPs, which, as people have repeatedly told you on this list, you shouldn't be doing anyway. Note further that no CPRNG can be safely used to generate OTPs--except for rather short ones--because the entropy of the resulting randomness stream is bounded by the size of the CPRNG state no matter how many bits of entropy you feed into it. The technical term for this is a stream cipher. -Ekr --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]