5

I'm thinking of this in the context of how much (kB/s) cryptographically secure entropy can be generated by a smart phone. For an example application: a VoIP app that continually generates new encryption keys.

Things I can think of off hand: - camera(s) - microphones - accelerometers - magnetometer - touch screen - signal strength and timing for Call, WiFi, Bluetooth, etc.

Clearly, each of these will generate differing amounts of signal (predictable data) and noise (the entropy that is wanted) but suitably combined it should be good.

Also if any one has any estimates on the amount of entropy various sources would produce under normal conditions that would also be on interest.

BCS
  • 75,627
  • 68
  • 187
  • 294

1 Answers1

9

The usual answer is that you do not need much entropy. 128 bits are enough; once you have 128 truly random bits, you can use them in a cryptographically secure pseudo-random number generator (PRNG) which will produce as many random bits as you need, at a high rate, limited only by the local computing power (on a smartphone, PRNG bandwidth will be in megabytes per second, not kilobytes per second).

Continuous entropy gathering is more a fetish than a scientific, rational need. Some say that getting "true" random protects you from any future cryptanalytic breach on the PRNG; but that argument holds only if you can get fresh uniformly random bits (which does not happen in practice: you need to apply a hash function to smooth out the gathered "noise") and if you use the random bits directly, not as keys in an encryption algorithm. A stronger case for continuous entropy gathering can be made about seed storage: the fear that an attacker, getting hold of the PRNG, could look at its entrails, recover internal state, and retroactively guess random bits which were previously emitted. Good PRNG protect against that. At the very least, you can reseed with 128 fresh bits every second, which is a low rate.

That being said, if you need entropy, the phone camera is probably the best source to use, because the CCD detector is very sensitive to heat-generated noise, and it outputs data with a very high bandwidth. A basic phone camera single picture will easily contain a megabyte worth of data, and, even if the phone is inside a pitch-back fridge, you will still have thousands of bits worth of noise (only one thousand bits of noise means that over the million pixels, 99.9% are "perfect", a somewhat ludicrous notion in a 400$ phone -- NASA engineers cannot do that in space probes which cost a million times more).

So just take a picture, hash it with any convenient hash function (e.g. SHA-256), and voila! you have 256 bits of entropy, which you use in a PRNG. If you really get nervous about the PRNG after some time, just take another snapshot.

Thomas Pornin
  • 72,986
  • 14
  • 147
  • 189
  • 1
    I would agree that in a single CCD image, there should be several hundred bits of noise. However, I'm not sure that I'm willing to believe (without further information) that the conditional entropy of an image is that high across sequential images, or if someone gets access to the physical camera for analysis. Is the noise really that uncorrelated over time? – Jack Lloyd Dec 22 '10 at 15:11
  • A given CCD has a non-uniform baseline: that's the picture you get fresh from the detector, when there is no light at all. That baseline tends to be constant over time (or to change only slowly). The circuitry and software using the CCD is supposed to already account for it. However, there is also a bit of low-amplitude noise on top of that, and that noise is what I am talking about. – Thomas Pornin Dec 22 '10 at 15:39
  • One solution to that would be to aggressively "compress" the image before adding it to the entropy pool. The normal compression formats likely wouldn't be suitable but might be good estimators of the contained entropy. – BCS Dec 22 '10 at 21:19