Adventures in random: /dev/urandom

[ColinTaylor]

I'm struggling to think of an actual real-world issue with an Asus home router being used normally that the inclusion of haveged will fix.

This sounds like a solution in search of a problem.

Side note: I do realise that I'm a hypocrite as I run John's fork which has included haveged for two and a half years now.

 

[smasher]

I'm struggling to think of an actual real-world issue with an Asus home router being used normally that the inclusion of haveged will fix.

Is ssh-ing into a router a real-world problem? How about initiating ip connections? Or disk access? Or generating SSL keys soon after booting? Or forking processes?

Sure, most people won't notice a huge benefit, but most people also won't notice the negligible footprint or resource use... And the net effect of resource use may actually support haveged.

I understand that most people aren't using their routers to mine bitcoins, but on the cost-benefit scale, I'm leaning towards net benefit.

 

[SomeWhereOverTheRainBow]

Bonus post...

RPi's have a build in HWRNG, so with rng-tools, and or uncomment the line below, and restart rng-tools

HRNGDEVICE=/dev/hwrng​

If one wants to see what randomness looks like - install the netpbm package, and run the line below

cat <source> | rawtoppm -rgb 256 256 | pnmtopng > random$(date +%Y%m%d%H%M%S).png
​

For example, on RPi - there one has to use sudo to capture direct from hwrng...

sudo cat /dev/hwrng | rawtoppm -rgb 256 256 | pnmtopng > random$(date +%Y%m%d%H%M%S).png​

View attachment 20042

how would you recommend fully taking advantage of RPi for its HWRNG ?

 

[RMerlin]

The primary obstacle is, it's one more moving piece to add to the puzzle. The more complex the architecture gets, the more likely you are to eventually have something break.

When it comes to tech, I always liked the KISS principle.

 

[SomeWhereOverTheRainBow]

The primary obstacle is, it's one more moving piece to add to the puzzle. The more complex the architecture gets, the more likely you are to eventually have something break.

When it comes to tech, I always liked the KISS principle.

It would be hard to use any other principle than KISS, when you are a one man dev with just a couple of contributors and collaborators to throw a patch here and a pull request there. At the end of the day, you have to be able to keep your code in sync with the mess of code asus brings to the equation.

 

[sfx2000]

I'm struggling to think of an actual real-world issue with an Asus home router being used normally that the inclusion of haveged will fix.

This sounds like a solution in search of a problem.

Side note: I do realise that I'm a hypocrite as I run John's fork which has included haveged for two and a half years now.

Some of the folks that use the 3rd party script packages will see benefit there.

 

[sfx2000]

The primary obstacle is, it's one more moving piece to add to the puzzle. The more complex the architecture gets, the more likely you are to eventually have something break.

Yes, and since it's included in the entware/entware-ng repos, folks have the option there to install haveged.