entropy /dev/random discussion

Development
21

Seems inverse.

Do we?

I.e. not secure solution.

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 Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND but still bad optics.)

22

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.

EDIT:
I saw on you other post that installing jitter stops the blocking anyhow so this is redundant.

1 Like
23

I asked and Stephan Mueller @smuellerDD is the author of jitterentropy-rng who also re-worked Linux kernel entropy replied:

24

From from @smuellerDD from here but the whole ticket is an interesting read:

Interesting discussion generally:

25

Perhaps we can ask for his opinion on vanheusden’s other entropy utilities discussed here.

These have since been removed from the live site but they live on archive.org

Ask him about Turbid listed on /Dev/entropy . It looks very interesting too.

1 Like
26

We should contact author first. I don’t think we ever did that yet?

Never looked more closely, because…

https://www.av8n.com/turbid/paper/turbid.htm

4 Configuration and Calibration

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.

27

No we only contacted randomsound’s author and he gave is discouraging feedback. Not sure if this applies to all sound entropy as a concept or just his implementation.

1 Like