Entropy Pool

[sfx2000]

Given that the increased entropy is lost when the router is restarted, would it be wiser to:

1) Regularly save the entropy and restore it on startup ? How would you do this ?

2) Or rely on rngtools and/or haveged to supply enough entropy on startup ?

It's not safe, in fact it is unwise, to save the state/last output of /dev/random and /dev/urandom - as now that data is not random...

haveged ramps up entropy fairly quickly - even cores with true HW RNG's need time to spin up...

As an example - did a reboot and tracking entropy with haveged...

@Denna As an example - did a reboot and tracking entropy with haveged...

 

[john9527]

And it appears as if the 'natural' entropy generation is really pretty slow (at least in the little bit of testing I did).

 

[sfx2000]

Here's a comment from the Linux kernel source that echos what you are suggesting. And I suppose you could use JFFS to persist the entropy bytes.

Don't do that...

 

[sfx2000]

And it appears as if the 'natural' entropy generation is really pretty slow (at least in the little bit of testing I did).

The older kernels are a bit slow at building the pool - and not having an RTC doesn't help :|

Kernel 4.4, 4.8, 4.9 are much better about this, but still not "perfect"...

Once we're through the boot cycle however, haveged fills the pool fairly quickly - see above...

 

[sfx2000]

Also, I think it's possible to increase the entropy pool size beyond 4096 bits, if you don't mind recompiling the Linux kernel.

One can, but it's likely not necessary - as long as the pool stays full - one is good enough - it's when the level drops to zero that processes can get blocked for items that call /dev/random...

Set the value too high, and one is sucking up memory that could be used for other things - which is important on small footprint devices that might only have 64/128 MB of RAM...

 

[kvic]

Fitz can find a way to patch the kernel. Dope the entropy pool in the random device's init stage...with the random bits stored on disk before shutdown. The stored bits on disk are as good as anything else as long as it's not stolen.

In other news, some interesting tidbits I saw. I have both haveged running on Edgerouter X (880MHz 1024Kc mips) and RT-AC56U (800MHz Cortex-A9 arm). Both devices have uptime of a week or so. Any observation is quite tentative..but I'll report back in six month's time or before my next reboots.

Here are the tidbits. haveged consumes 0.14s CPU time per one hour uptime of ERX. The same is 0.082s per one hour uptime of RT-AC56U. So seems the workload on my ERX consumes more entropy.

Of course, it could also be due to haveged works differently on different microarchitectures. But less likely (my thought so far) since the loop of cache avalanche in haveged is same.

Also ERX has a 3.10 kernel. RT-AC56u has a 2.6 kernel. No much difference in quality in random numbers generated from /dev/random. I heard there was a major enhancement in mid 2012...apparent little effect on generated numbers. Perhaps the seeding process is enhanced somewhat.

What's new in kernel 4.x about /dev/random?

 

[sfx2000]

No much difference in quality in random numbers generated from /dev/random.

I have to chuckle a bit here - based on earlier publc/private discussions...

One of Albert Einstein’s most famous statements is “God does not play dice with the universe”

/dev/random and /dev/uramdom are pretty safe these days - haveged fills the pool fast, and it's 'reasonably' random....

 

[kvic]

I have to chuckle a bit here - based on earlier publc/private discussions...

Pls don't mis-quote me. Our earlier discussions elsewhere was on the speed of CBC vs GCM. I see little relevance to /dev/random. Also the sentence you quoted, I was referring to kernel 2.6 vs kernel 3.10 where some people may expect noticeable difference with the major enhancement went in mid 2012. There was none based on blind test of the generated numbers.

One of Albert Einstein’s most famous statements is “God does not play dice with the universe”

/dev/random and /dev/uramdom are pretty safe these days - haveged fills the pool fast, and it's 'reasonably' random....

I would agree. Going back to the very first statements I made on this thread, ppl really don't have to worry about entropy on home routers. Malicious attacks by entropy estimation is agreed by researchers very difficult.

And more...from entropy to the output of /dev/random, it's figuratively a decade long journey. From the output of /dev/random to use in applications like openssl/sshd/web servers etc, add another few decades of convolution.

I guess enough entropy for some of us. Let's find some fun elsewhere (...why not Let's Encrypt?)

 

[sfx2000]

Pls don't mis-quote me

I don't - I think we're fairly aligned... my point was really this - play with random numbers at one's own risk - crypto, kernel, etc...

Let's Encrypt is likely another discussion...

 

[Denna]

Wouldn't writing to a file create a vulnerability in itself ?

Even if you deleted the file after loading it, the deleted file would still remain on the storage device, correct ?

If you stored the file on an encrypted drive with LUKS, you'd have to come up with a way to enter the passphrase from an external device to unlock the volume, which is an entirely different project unto itself.

 

[Fitz Mutch]

Fitz can find a way to patch the kernel.

This might be a good reason to backport a modern random.c to Linux 2.6.36, then verify with dieharder? This significant RNG change appeared in the Linux kernel as early as 3.16.43 and it's still there in 4.x. Which kernel version would you backport for random.c?

/*
...

 * Our mixing functions were analyzed by Lacharme, Roeck, Strubel, and
 * Videau in their paper, "The Linux Pseudorandom Number Generator
 * Revisited" (see: http://eprint.iacr.org/2012/251.pdf).  In their
 * paper, they point out that we are not using a true Twisted GFSR,
 * since Matsumoto & Kurita used a trinomial feedback polynomial (that
 * is, with only three taps, instead of the six that we are using).
 * As a result, the resulting polynomial is neither primitive nor
 * irreducible, and hence does not have a maximal period over
 * GF(2**32).  They suggest a slight change to the generator
 * polynomial which improves the resulting TGFSR polynomial to be
 * irreducible, which we have made here.
 */
...

 

[Denna]

After reading the article below, it would appear that additional RNG sources are either unnecessary or represent a possible vulnerability.

https://blog.cr.yp.to/20140205-entropy.html

How much entropy does a home router running dnscrypt-proxy and a VPN client really need at one time ? Even if you're using Perfect Forward Secrecy ?

This entire thread will be rendered moot when attackers get their first quantum computer. At that point, encryption will be rendered pointless because it will be quite a while for the cost of quantum computers to come down to provide quantum encryption for the masses.

https://www.sciencealert.com/google-s-quantum-computer-is-100-million-times-faster-than-your-laptop

https://en.wikipedia.org/wiki/Quantum_computing#Timeline

End on a good note, right ?

 

[Fitz Mutch]

Is it possible to mix in your own "random noise" to /dev/urandom at startup? Does it help? Unfortunately, this will not increase entropy_avail though. Example:

/jffs/scripts/init-start

#!/bin/sh
/bin/sleep 1
/usr/bin/head -n1 /proc/dmu/temperature >/dev/urandom
/usr/sbin/wl -i eth1 phy_tempsense >/dev/urandom
/usr/sbin/wl -i eth2 phy_tempsense >/dev/urandom
/usr/sbin/wl -i eth1 noise >/dev/urandom
/usr/sbin/wl -i eth2 noise >/dev/urandom
/usr/bin/head -n3 /proc/timer_list >/dev/urandom

 

[sfx2000]

How much entropy does a home router running dnscrypt-proxy and a VPN client really need at one time ? Even if you're using Perfect Forward Secrecy ?

While entropy is valuable to crypto, randomness is also important for general security and processes inside the OS... linux uses randomness to muck about addresses for processing in the stack and heap, as do other OS's these days - we don't want processes/threads to be static there - hard enough these days with heap-smashing attacks and whatever...

Going back to the genesis of the thread here - it's not really about security, but about how linux works across all bounds - and the pool running shallow does impact performance - and there's a good couple of approaches...

1) leave it alone - the kernel's RNG is good enough - but it is, erm, slow
2) for Devices that have a HW RNG - rng-tools is good enough
3) for Devices that don't have a HW RNG - haveged is a good answer

 

[sfx2000]

This might be a good reason to backport a modern random.c to Linux 2.6.36, then verify with dieharder? This significant RNG change appeared in the Linux kernel as early as 3.16.43 and it's still there in 4.x. Which kernel version would you backport for random.c?

Might be worth backporting if possible - problem here is AsusWRT is still basically back in the early 2K period with 2.6... breakage might happen here..

 

[Fitz Mutch]

Example of high quality random number generator (but slow) using an outdoor IP network camera as the entropy source (moving trees, sun, clouds, people, etc.). Then compute a SHA512 hash on the image file.

This sample code will retrieve a picture from the camera and pipe it to the hash function, and then print the result as a number.

wget -q -O - '--http-user=xxxxx' '--http-password=xxxxx' http://192.168.1.110/cgi-bin/snapshot.cgi?channel=0 | sha512sum --binary | cut -d' ' -f1

 

[sfx2000]

Example of high quality random number generator (but slow) using an outdoor IP network camera as the entropy source (moving trees, sun, clouds, people, etc.) Then compute a SHA512 hash.

wget -q -O - '--http-user=xxxxx' '--http-password=xxxxx' http://192.168.1.110/cgi-bin/snapshot.cgi?channel=0 | sha512sum --binary | cut -d' ' -f1

Many years back - I was in the business of cell phones - and we had to do some random numbers - subsidy locks, etc...

Recall that before digital, back in the analog TV days - empty channels there were static, basically echoes of the big bang...

To get some random values - only to 6 numbers, but still - we did two TV tuners on the analog side did a A to D 32 bit conversion, and then XOR'ed the numbers as a seed into a PRNG...

 

[kvic]

This entire thread will be rendered moot when attackers get their first quantum computer. At that point, encryption will be rendered pointless

No worries. Quantum cryptography is being actively researched and with huge progress! China had deployed the first commercial optical fibre (>1000km) with quantum cryptography, and followed by the first experiment of quantum cryptography over satellite links last year.

I'm sure everyone in the game is on the race to commercialise it.

 

[bigeyes0x0]

Well just added HW RNG support to my script https://www.snbforums.com/threads/release-dnscrypt-installer-for-asuswrt.36071/page-10#post-323163 . It's working for what it is .

cat /dev/random | rngtest -c 1024
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20480032
rngtest: FIPS 140-2 successes: 1024
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=198.192; avg=401.064; max=2969.178)Kibits/s
rngtest: FIPS tests speed: (min=2.874; avg=30.487; max=35.585)Mibits/s
rngtest: Program run time: 50514683 microseconds

 

[Fitz Mutch]

Well just added HW RNG support to my script https://www.snbforums.com/threads/release-dnscrypt-installer-for-asuswrt.36071/page-10#post-323163 . It's working for what it is .

Did you try feeding rngtest directly with /dev/ttyACM0? Remember to kill haveged before you run the tests.

Example: test Raspberry Pi 2 hardware RNG

#sudo cat /dev/hwrng | rngtest -c 10000
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 200000032
rngtest: FIPS 140-2 successes: 9996
rngtest: FIPS 140-2 failures: 4
rngtest: FIPS 140-2(2001-10-10) Monobit: 1
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 2
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=19.729; avg=1061.172; max=6510416.667)Kibits/s
rngtest: FIPS tests speed: (min=896.628; avg=10733.068; max=11335.607)Kibits/s
rngtest: Program run time: 203342304 microseconds