# Entropy of Androids motion-sensor data

My app on Android uses the built-in motion sensors to collect seed-data for the PRNG (java.security.SecureRandom) that is later to be used for key-generation. The user is told to shake the device so the incoming data should be somewhat pretty random. Also, too slow movements are ignored in order to avoid getting only 0s as seed if the device was not moved during the time of "recording".

In detail: Teh length of the movement-vector is calculated ($l = sqrt(x^2 + y^2 + z^2)$) and $9.81$ is subtracted from it in order to ignore gravity. If $l$ is less than 81% of the sensors Peek value the set of values is ignored. Otherwise the resulting values for x, y, z are beeing muliplied by $2^{28}$ (because bit-shifting is not supported on floats in Java), then XORed. These values then fill an array like that:

dataStack[dataSetsRecorded++ % dataStack.length] ^= value;


The question is: is that a high entropy or can this be predicted (e.g. because most phone users would shake the phone up and down but not sidewise and tablet users would rather tilt than shake the device)? Thanks :)

-
Entropy according to whom? In other words, what is your attacker model? Does the attacker have software implanted on the phone? If so, the entropy will be very low. Is the attacker allowed to video record the user shaking their device and take it back to the lab to analyze it, modeling the motion sensor to try to figure out what measurements were generated? Possibly low entropy in this case too. Or is the attacker assumed to not have software on the phone and not be within distance to gather information about the shaking process? –  mikeazo Mar 5 '14 at 12:16
No, i am not asking for code review. Im asking whether the data gathered from the sensors has enough entropy. For further explanation: the -9.81d is there to ignore gravity (and i hardly think that astronauts will ever be using that app). Worst case: the attacker has software running on the device. Expected case: the attacker gets the resulting public-key and has less effort to factor the key by guessing the directions the generating device was moved to. –  marstato Mar 5 '14 at 12:45
I disagree with those who say this is off-topic (although you might want to get rid of the code, as it's superfluous to your question). You're basically asking whether external input collected via a device's sensors has high entropy, and is suitable for feeding into a well-vetted CSPRNG. You should check out this question ... I would say the same principles apply. –  hunter Mar 5 '14 at 13:05
@hunter that is exactly what i am asking AND wheter the way i use it is flawed in any way (that dataSetsRecorded % dataStack.length thing). –  marstato Mar 5 '14 at 13:59
The original code did ((int) x) ^ ((((int) y) ^ ((int) z)) << 16), which is not accurately summarized by XORed. Also it multiplied by the float obtained from 0xFFFFFFF, which is $2^{28}-1$. We still do not have a model of how $x$, $y$, $z$ are derived, and most importantly a failure model of that. Much of the art of TRNG design is checking the source of entropy against its likely failures, given a model of the source; see this. Also: I guess $x$ $y$ $z$ are about acceleration, not movement as presently stated. –  fgrieu Mar 5 '14 at 15:34