# Practical sources of entropy on an Android device?

What Android API's can be used a practical sources of entropy ?

Given the requirement of sourcing entropy on the phone for purposes of seeding a PRNG, what are good options ?

Edit:

I have a hard external requirement to periodically supplement the entropy of the RNG, which in the case of SecureRandom, I will do by calling setSeed and passing in the new entropy.

The Android docs for setSeed state: The given seed supplements, rather than replaces, the existing seed. Thus, repeated calls are guaranteed never to reduce randomness..

As a result, I'm pretty confident that this is the safe and correct way to supplement the entropy of the RNG, but I need guidance as to appropriate on-device sources of entropy.

I have a FIPS compliant HSM on the server side that will contribute, but I need a safe source of additional entropy on the mobile device side.

Recommended options include the lower-order bits of random chunks of memory and phone sensors, and I would appreciate comment in this regard.

• As the hardware in cell phones, particularly android, is definitely lowest bidder, even if you get a good seed, you still have issues: cwe.mitre.org/data/definitions/338.html. Assuming that the PRNG quality doesn't bother you, can you use an external source for the seed? Such as random.org? – b degnan Jun 1 '20 at 10:40
• @bdegnan random.org is not safe since you don't have any guarantee that it's really random and not being logged. – Conrado Jun 1 '20 at 11:53
• SO Q/A [Where can I get a reliable source of entropy (real randomness byte[])?](stackoverflow.com/a/51787670/1820553) – kelalaka Jun 1 '20 at 15:34
• @Conrado physics doesn't give you very good sources locally as they are: slow, and power hungry. As a hardware person, you generally make things less good for the sake of power. The idea that an internal source would necessarily be better/worse is mostly a function of management. The best answer would probably be "if you have an accelerometer, shake vigorously" – b degnan Jun 1 '20 at 17:01
• @bdegnan Linux uses a bunch of different sources for seeding its RNG, it doesn't even need special hardware for that (it uses timings of network and disk events), though a lot of ARM SoCs already provide hardware RNGs. The point is that all of that is already handled by the kernel, so just use SecureRandom. – Conrado Jun 1 '20 at 19:25

• Yes. Reading /dev/urandom with one's favorite file API will do in native code.Or /dev/random is you want "true entropy" for some vague definition of that. – fgrieu Jun 1 '20 at 12:18
• @fgrieu Is there anything to the urban myth that /dev/random is somehow "better"? I read so many conflicting things about it. Some say /dev/urandom is just as good and you're an idiot for using /dev/random, others say it's actually better and you should never use /dev/urandom as source for randomness in cryptographic processes. I tried looking at this question but it could be out of date these days. – MechMK1 Jun 1 '20 at 20:37
• @MechMK1: I have a marvelous answer to your question-as-comment, but the limited space a crypto.SE comment allows won't allow me to expose it here :-). Plus the whole question, however interesting, is more about the history of pitfalls in Unixes implementations, than modern academic crypto. Thus I'm afraid it's kinda off-topic. Therefore I'll only second David Schmartz, and that baring availability of getrandom, on a platform I'd really trust I'd use /dev/urandom, rather than mix in extra entropy source for peace of mind as I've sometime done in professional practice. – fgrieu Jun 2 '20 at 4:10