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 ?


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.

  • $\begingroup$ 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? $\endgroup$ – b degnan Jun 1 at 10:40
  • 3
    $\begingroup$ @bdegnan random.org is not safe since you don't have any guarantee that it's really random and not being logged. $\endgroup$ – Conrado Jun 1 at 11:53
  • 1
    $\begingroup$ SO Q/A [Where can I get a reliable source of entropy (real randomness byte[])?](stackoverflow.com/a/51787670/1820553) $\endgroup$ – kelalaka Jun 1 at 15:34
  • 1
    $\begingroup$ @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" $\endgroup$ – b degnan Jun 1 at 17:01
  • 1
    $\begingroup$ @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. $\endgroup$ – Conrado Jun 1 at 19:25

Just use SecureRandom and let the OS take care of it.

| improve this answer | |
  • $\begingroup$ 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. $\endgroup$ – fgrieu Jun 1 at 12:18
  • $\begingroup$ I don't like comment only answers. Also, the /dev/urandom is under the change in Linux. It would be no more blocking. $\endgroup$ – kelalaka Jun 1 at 15:06
  • $\begingroup$ @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. $\endgroup$ – MechMK1 Jun 1 at 20:37
  • 3
    $\begingroup$ @MechMK1 Unfortunately, neither of those APIs does what most people want. Fortunately, Linux now has getrandom which does what most people actually want and eliminates the need to choose between two APIs that almost do what you want but one sometimes doesn't block when you absolutely need it to and one sometimes blocks when you definitely don't want it to. $\endgroup$ – David Schwartz Jun 1 at 21:04
  • 2
    $\begingroup$ @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. $\endgroup$ – fgrieu Jun 2 at 4:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.