5

I need to generate a cryptographically secure random number on iOS and Android. I could use a software approach or leverage the built in OS API for this.

In each case, is it better to generate a secure random number when no other processes are running?

I ask because I'm thinking of displaying an animation during the generation and want to know if the animation will affect the RNG positively or negatively... especially because I'm unsure of how the internal threading model is.

In case it matters (w.r.t. the threading model) in iOS I'm using Objective C, and with Android I'm using an alternative to the Dalvik kernel produced by Xamarin, which has its own threading options. Regardless, I'm interested in any Dalvik information you may have, since I can interopt with that.

2 Answers 2

2

To get randomness, you must obtain sufficient initial entropy from some "really random" events, that come from physical systems. Once you have sufficient initial entropy, you can extend it indefinitely with a cryptographically secure PRNG. The PRNG being a deterministic process, its output is not impacted by whatever other process may run at the same time on the machine.

The OS kernel is in ideal position to collect that initial seed, since it has direct access to the hardware. A good OS will collect hardware events to feed its internal pool, and run the PRNG, and provide an API to get the PRNG output. On iOS, this is the SecRandomCopyBytes() function, that itself reads the /dev/random special file (in iOS, like in OS X and FreeBSD, /dev/random is identical to /dev/urandom). By using it you are already doing fine; it already has all the cryptographic security that you can reasonably hope for; its security won't be impacted by running animations since the initial seed is gathered quite early in the booting process. On Android, use java.security.SecureRandom -- same discussion (it uses Linux's /dev/urandom).


In much older days, some people were talking about Java applets, that, by definition, were sandboxed and could not access the OS to obtain good randomness. These applets thus needed to find random events from other sources, and about the only one that remained was measuring the speed at which the OS scheduler could switch between two threads (e.g. see this code). That thread-spinning method required an otherwise mostly idle machine; otherwise, the produced numbers were severely non-random. Other methods leveraged the user: they asked the user to wiggle the mouse, and the applet would use the successive pointer positions as source of entropy.

Fortunately, these atrocious gimmicks are things of the past (or so we hope... because sometimes, some developers for banking systems get "creative"). For an app on a smartphone, you have access to the OS facilities, so use them and be happy.

0

Cryptographically secure random number generators are deterministic mathematical processes for given arguments, and do not care about the factors that having running programs affects - i.e. the kernel state and the data stored in RAM. There is no reason that other programs would affect the operation of these generators.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .