Sources of entropy?

Sources of entropy?

[Robin Getz]

I'm just wondering what people using on standard embedded/headless/diskless 
targets (which do not have hw random number generators) as a source of 
entropy - since networking was removed as an entropy source circa 2.6.26

On my target:

root:/> cat /proc/sys/kernel/random/entropy_avail
0

is about all I get... (since I'm not running any userspace utils yet).


I have seen rngd, clrngd, audio_entropyd, & video_entroyd - but I was just 
wondering what others were actually using. (I was cautioned that everything 
was pretty CPU intensive, since they all have a FIPS testing to ensure 
randomness)...

Thanks in advance.
-Robin

Re: Sources of entropy?

[David VomLehn]

Robin Getz wrote:
> I'm just wondering what people using on standard embedded/headless/diskless 
> targets (which do not have hw random number generators) as a source of 
> entropy - since networking was removed as an entropy source circa 2.6.26
> 
> On my target:
> 
> root:/> cat /proc/sys/kernel/random/entropy_avail
> 0
> 
> is about all I get... (since I'm not running any userspace utils yet).
> 
> I have seen rngd, clrngd, audio_entropyd, & video_entroyd - but I was just 
> wondering what others were actually using. (I was cautioned that everything 
> was pretty CPU intensive, since they all have a FIPS testing to ensure 
> randomness)...

The answer on the box I'm working on is: very little. I need to generate 
  an Ethernet MAC address and had to come up with way so that few random 
bits I had were sufficient, in my particular environment, to avoid 
address collisions.

Re: Sources of entropy?

[Jamie Lokier]

Robin Getz wrote:
> I'm just wondering what people using on standard embedded/headless/diskless 
> targets (which do not have hw random number generators) as a source of 
> entropy - since networking was removed as an entropy source circa 2.6.26

You might not have much real entropy to use.  I guess networking was
removed because it's an obvious attack vector.

On my devices, I save the entropy pool to flash on shutdown and merge
it back on reboot.  This lets cumulative history build.
    
    [shutdown]
    dd if=/dev/urandom of=$ENTROPY_STORE.new bs=512 count=1 2>/dev/null \
       && mv $ENTROPY_STORE.new $ENTROPY_STORE \
       || rm -f $ENTROPY_STORE.new

    [boot]
    dd if=$ENTROPY_STORE of=/dev/random bs=512 2>/dev/null

You'll still drain the pool quickly so may need to use /dev/urandom
for everything (e.g. by linking /dev/random -> /dev/urandom), but
keeping history does mean you get more real entropy from /dev/urandom,
even though entropy_avail cannot estimate it (and the lower bound is
still zero, if what you did before has always been predictable).

> I have seen rngd, clrngd, audio_entropyd, & video_entroyd - but I was just 
> wondering what others were actually using. (I was cautioned that everything 
> was pretty CPU intensive, since they all have a FIPS testing to ensure 
> randomness)...

You can write anything you think is an entropy source to /dev/random,
and it won't increase the entropy estimate but it will increase real
entropy if your source has any.  So you could add low-order bits from
high-resolution timing data from your network application from time to
time, for example, if you think it's worth it.

That won't make /dev/random show confirmed non-zero entropy, but that
might not be feasible on your device anyway.

-- Jamie

Re: Sources of entropy?

[Nicholas Mc Guire]

On Tue, 24 Mar 2009, Robin Getz wrote:

> I'm just wondering what people using on standard embedded/headless/diskless 
> targets (which do not have hw random number generators) as a source of 
> entropy - since networking was removed as an entropy source circa 2.6.26
>
without claiming that this is actually usable at this point but a simple
source of entropy that looks quite good is simply to use the timer-counter/TSC
or what ever available. The attached trng.c has been tested on a few X86
systems and produces remarkably good random numbers - this might be suitable
if you have no other sources available.

The actual source of randomness simply is that sampling the LSB of what ever
timer source is available is of lower granularity than the system jitter 
(scheduling jitter actually) - so this should be quite generally applicable.
In fact on some of the tested X86 system the randomness was good up to the
10 or 11th bit of the TSC.

 
/* naive true random number generator in software - this seems to be doing
 * better than /dev/random on most linux boxes ;)
 *
 * Copyright OpenTech EDV Research GmbH 2009
 * Author Der Herr Hofrat, <der.herr@hofr.at>
 * License GPL V2 - see http://www.gnu.org/copyleft/gpl.html for more
 *
 * cmpile: gcc -O2 trng.c -o trng
 * usage: ./trng > rand_data
 *
 * what is this doing ?
 * Simply take the non-determinism of intel architectures at the instruction
 * level and sample the TSCs LSB - bit shift it into an array and through
 * most of it away again (this could be optimized - but thats not essential
 * here) - the output is by all standards truly random 
 *
 * first "test"
 *
 * aetsch:~# ./trng > 1
 * ls -aetsch:~# ls -l 1
 * -rw-r--r-- 1 root root 8192 2008-10-19 14:03 1
 * aetsch:~# bzip2 1
 * aetsch:~# ls -l 1.bz2
 * -rw-r--r-- 1 root root 8679 2008-10-19 14:03 1.bz2
 *
 * indicate very good randomness as bzip is not able to compress anything!
 */

#include <stdio.h>

/* read the tsc snip of the LSB and shift it into a long long
 * usleep(something) to ensure that the CPU is sufficiently randomized
 * so we have NO deterministic (periodic) and thus non-random access
 */
__inline__ unsigned long long int sample_tsc(void)
{
	unsigned long long int x,res;
	int i;
	res=0;
	for(i=0;i<32;i++){
		__asm__ __volatile__("rdtsc\n\t":"=A" (x));
		res|=((x&0x01LL)<<i);
		usleep(10);
	}
	return res;
}

int main(int argc, char **argv)
{
	unsigned int n;

	n=0;
	/* simply dump the bit patters to stdout */
	while(n++ < 8192){
		printf("%c",(sample_tsc()&0x00FFLL));
	}
	return 0;
}

Re: Sources of entropy?

[Mike Frysinger]

On Thu, Apr 2, 2009 at 07:45, Nicholas Mc Guire wrote:
> On Tue, 24 Mar 2009, Robin Getz wrote:
>> I'm just wondering what people using on standard embedded/headless/diskless
>> targets (which do not have hw random number generators) as a source of
>> entropy - since networking was removed as an entropy source circa 2.6.26
>
> without claiming that this is actually usable at this point but a simple
> source of entropy that looks quite good is simply to use the timer-counter/TSC
> or what ever available. The attached trng.c has been tested on a few X86
> systems and produces remarkably good random numbers - this might be suitable
> if you have no other sources available.

unfortunately on Blackfin parts, the TSC (we call it "CYCLES" as that
is the actual register name) is writable from userspace

i have used this in the bootloader as a simple way of getting a little
bit of entropy, but then i found that our system is too reliable in
booting -- it tends to take the exact same amount of time to boot to a
prompt
-mike