Entropy Pool

[Fitz Mutch]

This patch has to be applied after each firmware upgrade, correct ?

No, actually my patch must be compiled into your firmware then flashed to the router. My patch does indeed break binary compatibility with the Asuswrt kernel, but I haven't had any issues so far. The problem would be if I changed something in the Linux kernel that the closed source pieces of Asuswrt dependended on. And, I have a lot of stuff removed from Asuswrt like DPI, so I wouldn't necessarily know if I broke something that I never use, like DPI. This patch works for me. The Tuxera filesystem drivers work fine too; I use this closed source piece.

 

[Denna]

@Fitz Mutch,

So the code below represents a solution for developers who want to run their fork of Asuswrt-Merlin, correct ?

https://github.com/blackfuel/rtlentropy-arm-asuswrt​

 

[Fitz Mutch]

So the code below represents a solution for developers who want to run their fork of Asuswrt-Merlin, correct ?

No, that script compiles a statically linked version of the rtl-entropy program that you may use with a DVB-T stick and the rngd program for real cheap hardware RNG on your Asus ARM router.

If rtl-entropy fails on your firmware, then you probably need to apply my kernel patch to your firmware. This means that you must recompile the Asuswrt-Merlin source code.

 

[sfx2000]

Tinkering about with Entropy... haveged, rng-tools, etc... with /dev/urandom, it comes down to time...

dd if=/dev/urandom of=1GB.img bs=512K count=2000
2000+0 records in
2000+0 records out
1048576000 bytes (1.0 GB) copied, 54.8335 s, 19.1 MB/s

This creates a random 1GB file... be careful, as this is dependent on external storage for devices... it's ARM and USB, so it's a bit slow...

sfx@raspy3:~/builds $ ll 1GB.img
-rw-r--r-- 1 sfx sfx 1048576000 Jul  2 20:39 1GB.img

BHR's on a native filesystem will go "boom" here without regrets... mostly because when one is on the shell, the genie does what is requested, assuming one knows the answer...gzip it, and you'll see and low entropy is what it is - this file is high entropy... it does not compress if the kernel is doing entropy correctly...

Anyways... after a bit, you should see a compressed file...

sfx@raspy3:~/builds $ ll
total 1024188
-rw-r--r--  1 sfx sfx 1048745942 Jul  2 20:39 1GB.img.gz
drwxr-xr-x 26 sfx sfx      12288 Jul  2 11:47 nmap
drwxr-xr-x 17 sfx sfx       4096 Jul  2 20:17 openwrt

Makes for a good test file across many tests - VPN, Samba, sftp...

 

[sfx2000]

Very nice.....I just added it to my fork What are you using for the write threshold (and any other tweaks to the start parms you may have used)?

Just want to follow up and see how things are working there...

 

[kvic]

Just want to follow up and see how things are working there...

Running very well on both Edgerouter X and RT-AC56U.

Edgerouter X: uptime 118 days in which haveged uses ~42 mins. So that's about 20s run per day.

RT-AC56U: uptime 64 hours. Also about 20s run per day.

My RT-AC56U is now used like a low-powered server which transfers ~20GB of encrypted packets on an average day. Interestingly haveged runtime is about constant.

I can't appreciate haveged more than ever before. Sitting in the background, doing hard work and keeping everyone in a safer place.

As an side, with that kind of workload, my RT-AC56U can't survive more than 30 days without a spontaneous reboot. Time to shop for a low-powered server.

 

[sfx2000]

It has come to my attention that the Tails distribution also has implemented haveged - which is a fair stamp of approval - they do modify the DAEMON_ARGS from the debian default of 1024 to 2048... Tails also uses rngd along with haveged, and the 2048 watermark keeps rngd from dominating the entropy pool (if a hardware rng is present).

# Configuration file for haveged
# Options to pass to haveged:
#   -w sets low entropy watermark (in bits)
DAEMON_ARGS="-w 2048"

 

[kvic]

It has come to my attention that the Tails distribution also has implemented haveged - which is a fair stamp of approval - they do modify the DAEMON_ARGS from the debian default of 1024 to 2048... Tails also uses rngd along with haveged, and the 2048 watermark keeps rngd from dominating the entropy pool (if a hardware rng is present).

# Configuration file for haveged
# Options to pass to haveged:
#   -w sets low entropy watermark (in bits)
DAEMON_ARGS="-w 2048"

I thought my approval said it all. Apparently I were talking to the wrong audience (*cough*) ^^

Happy Holidays!

 

[sfx2000]

Found a nice little surprise the other day - the BCM2708/2709/2710 chips used with the RPi's actually do have a Hardware RNG implemented - they use thermal deltas supposedly...

Pretty easy to enable with the current Raspbian kernels as the kernel module is bcm2708-rng is built in

to enable it...

sudo apt install rng-tools

then edit the /etc/default/rng-tools file, adding the following line item...

HRNGDEVICE=/dev/hwrng

the start the rng-tools service...

sudo service rng-tools start

To make the Pi's TRNG available for other devices - add the following line to /etc/rc.local

stty -F /dev/ttyAMA0 -echo raw 115200 
dd if=/dev/hwrng of=/dev/ttyAMA0 &

Just keep in mind that the 40 pin connector is 1.8VDC, so one has to find a TTL adapter, and just hook up the pins accordingly - if USB, then connect to Pin 8 (Tx) and Pin 6 (GND), and disable the PI's serial port via raspi-config

Neat stuff... between enabling the Pi's HW RNG and Haveged running on the Pi - should keep the entropy pool very full and very random.

Makes me wonder if that functional IP block was included in other recent Broadcom silicon...

 

[sfx2000]

My RT-AC56U is now used like a low-powered server which transfers ~20GB of encrypted packets on an average day. Interestingly haveged runtime is about constant.

I can't appreciate haveged more than ever before. Sitting in the background, doing hard work and keeping everyone in a safer place.

As an side, with that kind of workload, my RT-AC56U can't survive more than 30 days without a spontaneous reboot. Time to shop for a low-powered server.

Pi3 would do the job, sitting there quietly doing it's thing and sipping power - using that along with the HW RNG thing I posted above... serves multiple purposes with a single cheap board...

 

[Jack Yaz]

Found a nice little surprise the other day - the BCM2708/2709/2710 chips used with the RPi's actually do have a Hardware RNG implemented - they use thermal deltas supposedly...

Pretty easy to enable with the current Raspbian kernels as the kernel module is bcm2708-rng is built in

to enable it...

sudo apt install rng-tools

then edit the /etc/default/rng-tools file, adding the following line item...

HRNGDEVICE=/dev/hwrng

the start the rng-tools service...

sudo service rng-tools start

To make the Pi's TRNG available for other devices - add the following line to /etc/rc.local

stty -F /dev/ttyAMA0 -echo raw 115200
dd if=/dev/hwrng of=/dev/ttyAMA0 &

Just keep in mind that the 40 pin connector is 1.8VDC, so one has to find a TTL adapter, and just hook up the pins accordingly - if USB, then connect to Pin 8 (Tx) and Pin 6 (GND), and disable the PI's serial port via raspi-config

Neat stuff... between enabling the Pi's HW RNG and Haveged running on the Pi - should keep the entropy pool very full and very random.

Makes me wonder if that functional IP block was included in other recent Broadcom silicon...

Sorry can you recommend a usb/gpio adapter to run this with?

 

[sfx2000]

Pi3 would do the job, sitting there quietly doing it's thing and sipping power - using that along with the HW RNG thing I posted above... serves multiple purposes with a single cheap board...

With Pi's - use /dev/urandom and haveged feeding it - the hwrng there on the Pi's is pretty slow...

Testing shows that haveged is more than good enough for most purposes - it's fast, and fairly random....

 

[sfx2000]

@sfx2000 the project is more like toy to me same for going the hw route. haveged is still there in my suite, just that you have the hw option if you want to.

That said, you seems to be well verse in these, if you have MIPS ASUS router, please help me with https://www.snbforums.com/threads/help-test-dnscrypt-installer-binaries-for-ac66u-or-n66u.38835/ , it should help all the MIPS router users want to use dnscrypt-proxy.

I've been spending some time lately with a MIPS24kc target (QCA9531/QCA9331) which is big endian - haveged works fine there with my custom OpenWRT 18.06 build for an IOT project I'm working on.

Little-endian targets like Broadcom and Ralink/Mediatek should be fine - and there's obvious benefit for stubby by keeping the entropy pools full. I can't test the MIPSEL stuff, as I don't have any hardware that support little endian.

 

[john9527]

I can't test the MIPSEL stuf

haveged is part of the base firmware on my fork for both MIPS and ARM...seems to work fine. (dnscrypt v1 had an entropy pool test at startup that would fail without it).

 

[Milan]

i am using haveged on my ac 3200 and no problems there

 

[smasher]

$ dieharder -a
#=============================================================================#
#            dieharder version 3.31.1 Copyright 2003 Robert G. Brown          #
#=============================================================================#
   rng_name    |rands/second|   Seed   |
       mt19937|  1.88e+07  |2795046327|

That's actually testing dieharder's implementation of the Mersenne Twister PRNG, not testing the router's /dev/*random devices.

Here's some explorations into the router's /dev/urandom device - https://www.snbforums.com/threads/adventures-in-random-dev-urandom.60238/