On Fri, Feb 17, 2012 at 4:51 PM, Phillip Hallam-Baker <[email protected]> wrote: > 1) Random seed installed during manufacture > 2) Random capture from embedded RNG source / environmental capture > 3) Random caputure from UI > 4) Obtain random data from the network > >[...] > 1) Is actually not as bad as might be imagined, you trust the > manufacturer not to backdoor your crypto so having them give you a > seed is not terrible.
Right. There's nothing wrong with this as a fallback. Also, we assume a clock or stable storage for a counter so as to avoid starting with the same seed every time. > 2) Is ideal but adds to hardware cost. Unless that is someone can work > out a cheap way to get random data into a D/A port or other I/O pin. A floating D/A input will do. Also, CPUs can implement an RNG relatively cheaply. Sun did it in UltraSPARC CPUs, and Intel does it now in theirs. As with all other things electronic is just a matter of getting it into one massively manufactured chip/chipset and then it will quickly get cheaper. (Smartphones, for example, are chuck-ful of inputs suitable for entropy gathering, and have modern CPUs. Even non-smartphone phones have lots of suitable inputs. You have to reach for devices like keyfobs to find devices where it'd be expensive to retrofit an RNG.) > 4) Is clearly sub optimal since the service knows the data sent. (4) is not so bad if you also have (1), because a) the vendor doesn't know the entropy obtained in (4) and the service in (4) doesn't know the vendor seed, thus if the device combines both then the vendor and service have to collude in order to recover the device's state. > How about this for a better protocol approach? > > Client generates random seeds. S1, S2 > Client sends Trunc(H(S1)) to the service > Service says 'hey I have seen that before' or 'nope it is new' + returns S3 > > Client generates new seed from H(S1 + S2 + S3 +c) > Where c is a counter that is incremented for each call for more random bits. Sure. And if you have RSA keys for the service and the client then you can authenticate the service and encrypt the entropy (so eavesdroppers can't see it). > Advantages: > > 1) The checking protocol is tied into the PRNG algorithm so that it is > really hard for the programmer to balls it up. If there are small enough perturbations in the seeding of the PRNG then eventually there will be enough devices with colliding state that will be detected. Yes, this is good. > 2) Only part of the ergodicity is checked, the protocol checks to see > that there are at least 128 bits worth of random data in the output. > > Cons: > > 1) Requires twice the amount of randomness to do the job right. Not necessarily. We should be willing to settle for computational entropy in many cases (i.e., it should be hard to recover the device's PRNG state from Trunc(H(S1)). > Also, this looks to me to be the sort of thing that you would want to > be a part of some form of device enrollment protocol. Yes. And if there's enough UI then the user can be asked to confirm that the public key of the RNG service is correct -- SSH-like, but since there will be few such services in any one org, it will generally be recognizable. Nico -- _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
