On Sat, Apr 2, 2011 at 10:22 AM, Tom Ritter <t...@ritter.vg> wrote: >> At most, I would think you'd only be able to collect a few bits. > > Agreed, I think using anything but the lowest bits would be dangerous. > But most smartphones (especially ones with GPS sensors) have other > sensors that would be better contributors of entropy, and aren't > monitorable by any remote adversary: Acceleration, Orientation, > Microphone, Camera, probably some others. You may also be able to get > some bits from the Antenna and Wifi Signals Strengths as well. Agreed. I even have a finger drawing program to extract random bits (if the user desires).
> But, most phone API's already provide a random number generator they > say is cryptographically sound. Java's SecureRandom on Android, > SecRandomCopyBytes on iOS, net.rim.device.api.crypto.RandomSource on > Blackberry, System.Security.Cryptography.RNGCryptoServiceProvider on > Windows, and CreateRandomL on Symbian. Is there a particular reason > you distrust or can't use one of those? Two reasons. The first is due diligence (paranoia?), the second is feasibility. For paranoia, I don't want to place 100% trust in the OS provided gear. For example, Ray Marsh recently discussed some considerations with Free BSD's prng. For me, its easier to use Crypto++'s X9.17 generator, and add extra entropy as required. For feasibility, I have some background tasks I need to perform (namely, zeroization). On Apple's iPhone, background processes are restricted to programs performing certain duties. Processing location data is one of the approved duties. So if I consume location data, I can enter the background and perform the other tasks. I know zeroization is another can of worms due to wear leveling. But if I can't execute, I can't perform zeroization and the game is over before it begins. Jeff _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
