Idea in above post would result in exactly the opposite of my idea. It would be similar to renaming /dev/random to /dev/random_original and then symlinking from /dev/urandom to /dev/random. Does not seem secure. (But this is based on some assumptions which are likely false anyhow as per https://www.whonix.org/wiki/Dev/Entropy#.2Fdev.2Frandom_vs._.2Fdev.2Furandom but still bad optics.)
It is secure. He does not know what we do about the difference between the random and urandom and that all that matters is early boot initialization of the RNG - they both use the same pool. The point is we are trying to eliminate the blocking for any software that insists on using random.
No. This part is besides the point. We are not interested in hwrng as a source but this daemon can be repurposed to feed random from urandom without any symlinking hacks.
It is all about the initialization of the pool which jitternentropy handles well to prevent bad seeds from being used. Otherwise there is no meaningful difference. We saw in DJB’s post that the idea if entropy being exhausted is laugable when the output of a single symmetric key is more than enough.
Instead of messing around with the naming and links you are achieving the same effect of feeding random to prevent blocking without complications.
I saw on you other post that installing jitter stops the blocking anyhow so this is redundant.
Note: You can skip this section if you’ve been given a suitable turbid.tbd configuration file and mixer configuration (.ctl) file.
Configuration is important. It is remarkably easy to mis-configure a soundcard in such a way that it produces much less randomness than it otherwise would. This section outlines the general procedure; see appendix B for details on specific soundcards.
…doesn’t seem like a drop-in solution. Maybe since lots of assumptions from the paper if I got that right (such as lots of entropy required and reseeding required) aren’t state of the art anymore… Could ask the author if turbid even uncalibrated could gather 256-bits of entropy in a reasonable timeframe? Even less might be OK since it would only be an additional mix-in.