Is Entropy Slowing Down Your Android Device?

January 4, 2013 by Mike Szczys 50 Comments

[Lambgx02] got tired of his Android device getting bogged down and decided to dig down to the cause of the issue. His investigation led him to believe that entropy is causing the slowdown. He believes that his workaround reduces 90% of the lag on the average Android device.

So how is it possible that entropy is causing the problem? It seems there is a bottleneck when an app requests a random number from the Linux kernel running at the lowest level of the device. Android is set up to use /dev/random for all random number requests, but [Lambgx02] says that location has a very shallow pool of numbers available. When they run out the kernel has to reload with a new seed and this is blocking the app that requested the data from continuing.

His solution was to write his own app that seeds /dev/random once every second using a number from /dev/urandom. He mentions that this might cause a security vulnerability as seeding the random data in this way is not quite as random. There may also be issues with battery life, so make sure to monitor performance if you give it a try.

[via Reddit]

Using A 555 Timer And ADC As A Random Seed

October 1, 2012 by Mike Szczys 15 Comments

Most toolchains for embedded system include support for random number generation. But if you’ve read the manual you’ll know that this is really just pseudo random number generation (PRNG). When calling this function the same numbers will always return in the same order unless a different random number seed is supplied in advance. [Gardner] put together a simple and cheap solution for deriving better random number seeds. He reads a voltage from a 555 timer using the ADC on the microcontroller. At first glance it may not seem like a great source of randomness, but he performed some testing and the results look quite promising.

The project is aimed at Arduino-based circuits, but any chip with an ADC will work. The 555 timer is used as a free running oscillator. We know that this not be very stable when compared to even the worst of crystal oscillators, but that’s what makes it work so well as a random seed source. Add to this the low parts count and small size of the additional circuitry and you’ve got a winning combination. So keep this in mind when you need a random number but don’t necessarily need rock solid entropy.

[via Reddit and Freetronics]

Hardware Based Randomness For Linux

February 6, 2010 by Mike Szczys 28 Comments

True randomness can be hard to come by in the digital world. [Andy Green] is making it easier to get true entropy by using this random USB dongle. The Whirlygig uses a CPDL to gather data from a set of of oscillators. The oscillators have a constantly fluctuating frequency due to temperature changes; if they run faster they generate more heat which in turn slows them down. This, along with the variable latency associated with polling a USB device, gives great depth of randomness. The device is detected and mounted under ‘/dev/hw_random’ and can then be fed into ‘/dev/random’ using the rng-tools package. [Andy’s] done a lot of testing, both on the hardware, and on the quality of randomness. We didn’t see an option to order this but he’s got hardware and firmware repositories so that you can throw one together yourself.

[Thanks Zunk]

A Random USB… Hourglass

December 21, 2009 by Jake W 20 Comments

[Peter] thought of a creative, way to generate random entropy for under $100.

The USB Hourglass combines a sand timer with a rotating mechanism and an optical beam through the center of the timer to observe the falling sand. The amount of light reaching a detector is digitized at frequent intervals and processed by a microcontroller to determine when to rotate the hourglass. The digitized light levels are also sent by USB to a host PC where they can be used as a source of random entropy. Power is supplied over the USB cable.

With the USB Hourglass, the user can look at the sand falling through the center of the hourglass and monitor the randomness in the USB output data. And one can read the code line-by-line, compile it, and upload it to the microcontroller using only open-source and widely supported tools.