Entropy Pool

[Denna]

Is there a way to install Dieharder on Asuswrt-Merlin ?

http://www.phy.duke.edu/~rgb/General/dieharder.php​

 

[bigeyes0x0]

@john9527 Really, but you can recompile these modules in I believe or we can modprobe in. Not really hard I think so. I have compiled the alsa driver for my model before, it works with my USB DAC but the router is too noisy for that purpose lol.

 

[sfx2000]

@kvic - Thanks for the info...I ran some tests and really didn't see any difference between the 32K and 16K default cache sizes. I also didn't compile with thread support since I saw it was still experimental. I initially chose 2048 for the write watermark (it was the default for rng-tools), and don't see any adverse effects. Just for completeness, here's my result on an AC68P, overclocked to 1.2GHz

Reason this discussion was timely.....dnscrypt added an entropy level 'check' as part of their startup. The router at boot was right on the edge of the value they were checking.

The defaults for haveged are good enough, and I would stay away from the "experimental" multi-thread option - it's not needed...

sfx

 

[sfx2000]

gah - not again... blocked by silly stuff...

@thiggins - how can we fix this?

 

[kvic]

Is there a way to install Dieharder on Asuswrt-Merlin ?

http://www.phy.duke.edu/~rgb/General/dieharder.php​

yes. If you asked earlier, I can offer you my binaries. Unfortunately I deleted them last night. But it's same to run on your PC

 

[kvic]

@kvic
Reason this discussion was timely.....dnscrypt added an entropy level 'check' as part of their startup. The router at boot was right on the edge of the value they were checking.

I've convinced myself haveged+/dev/random produces very high quality random numbers!

Good that your build is ahead of the curve! It benefits not only dnscrypt but sshd and https webui. They're very vulnerable (relatively speaking) as-is. But with you bringing in haveged, users are assured of very good random numbers right after boot.

Supply all caches for different models if you can. Not a big deal but 32k cache carries more "entropy" than 16k cache. So really shall not be left un-harvested..

 

[sfx2000]

@bigeyes0x0 - not so much benefit, and effort for a very few - the SW solution with haveged/rngd is probably good enough...

@Denna - better to hit up the entware/optware folks to bring in dieharder if one really wants... with dieharder, haveged passes...

 

[sfx2000]

I've convinced myself haveged+/dev/random produces very high quality random numbers!

I've probably convinced you, and others - this is how open source works, when it works

 

[bigeyes0x0]

@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.

 

[sfx2000]

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 don't do MIPS - ARM and x86 keeps me busy enough, lol...

My involvement with AsusWRT is as an informed observer, looking in from the outside - I offer hints and general contributions across wireless and ARM cpu stuff...

I appreciate that MIPS can perform very well, just not my area of expertise

 

[Veldkornet]

Do the ARM versions not have a hardware module that can be enabled like on the RaspberryPi and then make use of /dev/hwrng?


Sent from my iPhone using Tapatalk

 

[sfx2000]

Do the ARM versions not have a hardware module that can be enabled like on the RaspberryPi and then make use of /dev/hwrng?

The pi stuff is kinda out of date...

the kernel mod no longer exists, but that's ok, it doesn't need to be, as it's built in... and haveged there (it's in the raspian repo's) is actually faster than the hwrng in the 2835 (2708) ARMv6...

 

[sfx2000]

Is there a way to install Dieharder on Asuswrt-Merlin ?

http://www.phy.duke.edu/~rgb/General/dieharder.php​

was a bit of pain to build... but at the end of the day... couple of weak items, but generally passed with haveged

sfx

$ dieharder -a
#=============================================================================#
#            dieharder version 3.31.1 Copyright 2003 Robert G. Brown          #
#=============================================================================#
   rng_name    |rands/second|   Seed   |
        mt19937|  1.88e+07  |2795046327|
#=============================================================================#
        test_name   |ntup| tsamples |psamples|  p-value |Assessment
#=============================================================================#
   diehard_birthdays|   0|       100|     100|0.60256659|  PASSED  
      diehard_operm5|   0|   1000000|     100|0.07022370|  PASSED  
  diehard_rank_32x32|   0|     40000|     100|0.17784530|  PASSED  
    diehard_rank_6x8|   0|    100000|     100|0.80585788|  PASSED  
   diehard_bitstream|   0|   2097152|     100|0.41778223|  PASSED  
        diehard_opso|   0|   2097152|     100|0.76204551|  PASSED  
        diehard_oqso|   0|   2097152|     100|0.35015079|  PASSED  
         diehard_dna|   0|   2097152|     100|0.12788252|  PASSED  
diehard_count_1s_str|   0|    256000|     100|0.54505096|  PASSED  
diehard_count_1s_byt|   0|    256000|     100|0.96779942|  PASSED  
 diehard_parking_lot|   0|     12000|     100|0.48712953|  PASSED  
    diehard_2dsphere|   2|      8000|     100|0.58931846|  PASSED  
    diehard_3dsphere|   3|      4000|     100|0.09927068|  PASSED  
     diehard_squeeze|   0|    100000|     100|0.75046600|  PASSED  
        diehard_sums|   0|       100|     100|0.44773303|  PASSED  
        diehard_runs|   0|    100000|     100|0.10338501|  PASSED  
        diehard_runs|   0|    100000|     100|0.97011787|  PASSED  
       diehard_craps|   0|    200000|     100|0.61118756|  PASSED  
       diehard_craps|   0|    200000|     100|0.69956421|  PASSED  
 marsaglia_tsang_gcd|   0|  10000000|     100|0.26501783|  PASSED  
 marsaglia_tsang_gcd|   0|  10000000|     100|0.57053545|  PASSED  
         sts_monobit|   1|    100000|     100|0.97881936|  PASSED  
            sts_runs|   2|    100000|     100|0.10399735|  PASSED  
          sts_serial|   1|    100000|     100|0.53407611|  PASSED  
          sts_serial|   2|    100000|     100|0.03805457|  PASSED  
          sts_serial|   3|    100000|     100|0.03956705|  PASSED  
          sts_serial|   3|    100000|     100|0.58571599|  PASSED  
          sts_serial|   4|    100000|     100|0.56874174|  PASSED  
          sts_serial|   4|    100000|     100|0.04393908|  PASSED  
          sts_serial|   5|    100000|     100|0.70348996|  PASSED  
          sts_serial|   5|    100000|     100|0.66169741|  PASSED  
          sts_serial|   6|    100000|     100|0.22543221|  PASSED  
          sts_serial|   6|    100000|     100|0.38395047|  PASSED  
          sts_serial|   7|    100000|     100|0.91441323|  PASSED  
          sts_serial|   7|    100000|     100|0.98937095|  PASSED  
          sts_serial|   8|    100000|     100|0.99866793|   WEAK  
          sts_serial|   8|    100000|     100|0.63893892|  PASSED  
          sts_serial|   9|    100000|     100|0.63550490|  PASSED  
          sts_serial|   9|    100000|     100|0.15116107|  PASSED  
          sts_serial|  10|    100000|     100|0.57306004|  PASSED  
          sts_serial|  10|    100000|     100|0.80585672|  PASSED  
          sts_serial|  11|    100000|     100|0.67899745|  PASSED  
          sts_serial|  11|    100000|     100|0.30536095|  PASSED  
          sts_serial|  12|    100000|     100|0.41719706|  PASSED  
          sts_serial|  12|    100000|     100|0.64721637|  PASSED  
          sts_serial|  13|    100000|     100|0.73677136|  PASSED  
          sts_serial|  13|    100000|     100|0.52156829|  PASSED  
          sts_serial|  14|    100000|     100|0.68926048|  PASSED  
          sts_serial|  14|    100000|     100|0.48586001|  PASSED  
          sts_serial|  15|    100000|     100|0.96613461|  PASSED  
          sts_serial|  15|    100000|     100|0.53939427|  PASSED  
          sts_serial|  16|    100000|     100|0.63923745|  PASSED  
          sts_serial|  16|    100000|     100|0.69735016|  PASSED  
         rgb_bitdist|   1|    100000|     100|0.22321355|  PASSED  
         rgb_bitdist|   2|    100000|     100|0.16814724|  PASSED  
         rgb_bitdist|   3|    100000|     100|0.96148147|  PASSED  
         rgb_bitdist|   4|    100000|     100|0.88697956|  PASSED  
         rgb_bitdist|   5|    100000|     100|0.83313688|  PASSED  
         rgb_bitdist|   6|    100000|     100|0.60561643|  PASSED  
         rgb_bitdist|   7|    100000|     100|0.10540463|  PASSED  
         rgb_bitdist|   8|    100000|     100|0.62222124|  PASSED  
         rgb_bitdist|   9|    100000|     100|0.18260905|  PASSED  
         rgb_bitdist|  10|    100000|     100|0.69386474|  PASSED  
         rgb_bitdist|  11|    100000|     100|0.39507452|  PASSED  
         rgb_bitdist|  12|    100000|     100|0.99478030|  PASSED  
rgb_minimum_distance|   2|     10000|    1000|0.52450131|  PASSED  
rgb_minimum_distance|   3|     10000|    1000|0.74764716|  PASSED  
rgb_minimum_distance|   4|     10000|    1000|0.63473060|  PASSED  
rgb_minimum_distance|   5|     10000|    1000|0.04077417|  PASSED  
    rgb_permutations|   2|    100000|     100|0.17369396|  PASSED  
    rgb_permutations|   3|    100000|     100|0.99120092|  PASSED  
    rgb_permutations|   4|    100000|     100|0.91403463|  PASSED  
    rgb_permutations|   5|    100000|     100|0.65840808|  PASSED  
      rgb_lagged_sum|   0|   1000000|     100|0.43611859|  PASSED  
      rgb_lagged_sum|   1|   1000000|     100|0.28297405|  PASSED  
      rgb_lagged_sum|   2|   1000000|     100|0.49760278|  PASSED  
      rgb_lagged_sum|   3|   1000000|     100|0.99625221|   WEAK  
      rgb_lagged_sum|   4|   1000000|     100|0.22210189|  PASSED  
      rgb_lagged_sum|   5|   1000000|     100|0.57665684|  PASSED  
      rgb_lagged_sum|   6|   1000000|     100|0.01702124|  PASSED  
      rgb_lagged_sum|   7|   1000000|     100|0.06738001|  PASSED  
      rgb_lagged_sum|   8|   1000000|     100|0.86508353|  PASSED  
      rgb_lagged_sum|   9|   1000000|     100|0.29070416|  PASSED  
      rgb_lagged_sum|  10|   1000000|     100|0.84167097|  PASSED  
      rgb_lagged_sum|  11|   1000000|     100|0.36918453|  PASSED  
      rgb_lagged_sum|  12|   1000000|     100|0.89480078|  PASSED  
      rgb_lagged_sum|  13|   1000000|     100|0.46134528|  PASSED  
      rgb_lagged_sum|  14|   1000000|     100|0.61863658|  PASSED  
      rgb_lagged_sum|  15|   1000000|     100|0.31866855|  PASSED  
      rgb_lagged_sum|  16|   1000000|     100|0.80726860|  PASSED  
      rgb_lagged_sum|  17|   1000000|     100|0.43705489|  PASSED  
      rgb_lagged_sum|  18|   1000000|     100|0.47957687|  PASSED  
      rgb_lagged_sum|  19|   1000000|     100|0.18729481|  PASSED  
      rgb_lagged_sum|  20|   1000000|     100|0.46135472|  PASSED  
      rgb_lagged_sum|  21|   1000000|     100|0.09089204|  PASSED  
      rgb_lagged_sum|  22|   1000000|     100|0.67811978|  PASSED  
      rgb_lagged_sum|  23|   1000000|     100|0.97705094|  PASSED  
      rgb_lagged_sum|  24|   1000000|     100|0.35150224|  PASSED  
      rgb_lagged_sum|  25|   1000000|     100|0.23028791|  PASSED  
      rgb_lagged_sum|  26|   1000000|     100|0.31077537|  PASSED  
      rgb_lagged_sum|  27|   1000000|     100|0.67050746|  PASSED  
      rgb_lagged_sum|  28|   1000000|     100|0.80429034|  PASSED  
      rgb_lagged_sum|  29|   1000000|     100|0.32071299|  PASSED  
      rgb_lagged_sum|  30|   1000000|     100|0.66122709|  PASSED  
      rgb_lagged_sum|  31|   1000000|     100|0.40904539|  PASSED  
      rgb_lagged_sum|  32|   1000000|     100|0.96775948|  PASSED  
     rgb_kstest_test|   0|     10000|    1000|0.40989789|  PASSED  
     dab_bytedistrib|   0|  51200000|       1|0.29099220|  PASSED  
             dab_dct| 256|     50000|       1|0.05487172|  PASSED  
Preparing to run test 207.  ntuple = 0
        dab_filltree|  32|  15000000|       1|0.49559879|  PASSED  
        dab_filltree|  32|  15000000|       1|0.87654489|  PASSED  
Preparing to run test 208.  ntuple = 0
       dab_filltree2|   0|   5000000|       1|0.89832193|  PASSED  
       dab_filltree2|   1|   5000000|       1|0.62012949|  PASSED  
Preparing to run test 209.  ntuple = 0
        dab_monobit2|  12|  65000000|       1|0.86755948|  PASSED

 

[sfx2000]

Run into this earlier this evening...

PRNG in VHDL (Chip Design Languange) as a cell that can be implemented on FPGA's

It's a bit long, but fun read...

http://fpgasite.blogspot.co.il/2017/04/pseudo-random-generator-tutorial.html

 

[bigeyes0x0]

FWIW, I've just added ability to install either rngd/haveged alone with my dnscrypt-proxy installer script https://www.snbforums.com/threads/release-dnscrypt-installer-for-asuswrt.36071/.

Advantage of this over entware-ng is this taking care of creating related startup scripts for you as well as having haveged/rngd started at init-start which is much earlier than post-mount can run. IOW the daemon should be available for httpds and stuffs at much earlier at boot.

 

[Fitz Mutch]

Well I bought this http://ubld.it/truerng_v3 and it's shipping to me at the moment.

The Linux UDEV rules for this TruRNG device says it is "CDC-ACM device". So when you plug it in, look for /dev/ttyACM0. The Asus router may report that you're plugging in a USB modem. However, it will probably work just fine... except maybe slower than built-in RNG hardware due to the USB stack overhead.

 

[bigeyes0x0]

The Linux UDEV rules for this TruRNG device says it is "CDC-ACM device". So when you plug it in, look for /dev/ttyACM0. The Asus router may report that you're plugging in a USB modem. However, it will probably work just fine... except maybe slower than built-in RNG hardware due to the USB stack overhead.

Yeah, I'm looking forward to play around with this .

 

[Denna]

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 ?
​

The question is in response to this excerpt from http://eprint.iacr.org/2006/086.pdf.

LRNG = Linux Pseudo-Random Number Generator

2.2 Initialization

Operating system startup includes a sequence of routine actions. This sequence includes the initialization of the LRNG
with constant operating system parameters and with the time-of-day, and additional disk operations and system events
which affect the LRNG using the interface for adding external entropy (discussed in Section 2.5). This sequence of
operations might be easily predicted by an adversary, especially in systems which do not have a hard drive. If no
special actions are taken, the LRNG state might include very limited entropy. (For example, the time of day is given as
a count of seconds and of micro-seconds, each represented as a 32-bit value. In reality these values have very limited
entropy as one can find computer uptime within an accuracy of a minute, which leads to a brute-force search of only
60 × 10^2 < 2^26 different options.)

To solve this problem, the LRNG simulates continuity along shutdowns and startups. This is done by saving a random-seed at shutdown and writing it back to the pools at startup. A script that is activated during system startups and shutdowns uses the read and write capabilities of the /dev/urandom interface to perform this operation.

During shutdown the script reads 512 bytes from /dev/urandom and writes them to a file, and during startup these bits are written back to the /dev/urandom device. This device is defined such that writing to it modifies the primary pool and not the urandom pool (as one could expect from its name). The resulting operations applied to the primary pool are pretty much identical to the effect of receiving these 512 bytes as the encoding of system events, and adding them to the primary pool using the usual procedure for adding entropy, which is outlined in Section 2.5. The only difference is that the added bytes do not increment the entropy estimation. The secondary pool and the urandom pool are refreshed by the primary pool, and therefore the script affects all three pools.

 

[Fitz Mutch]

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

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.
https://github.com/RMerl/asuswrt-me...linux/linux-2.6.36/drivers/char/random.c#L147

...

 * Ensuring unpredictability at system startup
 * ============================================
 *
 * When any operating system starts up, it will go through a sequence
 * of actions that are fairly predictable by an adversary, especially
 * if the start-up does not involve interaction with a human operator.
 * This reduces the actual number of bits of unpredictability in the
 * entropy pool below the value in entropy_count.  In order to
 * counteract this effect, it helps to carry information in the
 * entropy pool across shut-downs and start-ups.  To do this, put the
 * following lines an appropriate script which is run during the boot
 * sequence:
 *
 *    echo "Initializing random number generator..."
 *    random_seed=/var/run/random-seed
 *    # Carry a random seed from start-up to start-up
 *    # Load and then save the whole entropy pool
 *    if [ -f $random_seed ]; then
 *        cat $random_seed >/dev/urandom
 *    else
 *        touch $random_seed
 *    fi
 *    chmod 600 $random_seed
 *    dd if=/dev/urandom of=$random_seed count=1 bs=512
 *
 * and the following lines in an appropriate script which is run as
 * the system is shutdown:
 *
 *    # Carry a random seed from shut-down to start-up
 *    # Save the whole entropy pool
 *    echo "Saving random seed..."
 *    random_seed=/var/run/random-seed
 *    touch $random_seed
 *    chmod 600 $random_seed
 *    dd if=/dev/urandom of=$random_seed count=1 bs=512
 *
 * For example, on most modern systems using the System V init
 * scripts, such code fragments would be found in
 * /etc/rc.d/init.d/random.  On older Linux systems, the correct script
 * location might be in /etc/rcb.d/rc.local or /etc/rc.d/rc.0.
 *
 * Effectively, these commands cause the contents of the entropy pool
 * to be saved at shut-down time and reloaded into the entropy pool at
 * start-up.  (The 'dd' in the addition to the bootup script is to
 * make sure that /etc/random-seed is different for every start-up,
 * even if the system crashes without executing rc.0.)  Even with
 * complete knowledge of the start-up activities, predicting the state
 * of the entropy pool requires knowledge of the previous history of
 * the system.

...

 

[Fitz Mutch]

Also, I think it's possible to increase the entropy pool size beyond 4096 bits, if you don't mind recompiling the Linux kernel.
https://github.com/RMerl/asuswrt-me...linux/linux-2.6.36/drivers/char/random.c#L257

#define INPUT_POOL_WORDS 128

The word size is 32 bits. So, if you want to increase the entropy pool size from 4096 bits to 16384 bits, for example, increase the INPUT_POOL_WORDS symbol from 128 to 512, then rebuild the firmware.