I’m working on the Entropy page of the wiki because it is empty. Currently, it is quite general because it’s better to write nothing than to write something wrong.
I have several questions to make it better:
Does IPFire use specific entropy sources (other than input, storage and interrupts) ? For instance, I notice that the entropy varies with the business of my connexion.
It seems that IPFires blocks the startup process of the system if the entropy is too low. Is it true ?
Are there specific features of IPfire that would be slowed down/blocked if entropy is too low ? I read that it depends on wether a function uses /dev/urandom or /dev/random.
question 2 … yes, I have an ipfire VM (in Proxmox) which starts slow since the entropy is very low and I have to wait till the counter “wait for entropy: 30/130” advances till it reaches 130, then ipfire starts. To accelerate this wait, I hit ENTER a bunch of times and the counter advances faster.
I have done some prior reading into entropy, however I am not an expert.
From what I understand if the system has low entropy it can slowdown VPN transfer speeds and likely increase certificate creation time.
You noticed it will slow down the boot process, I believe on boot it is SPRNG looking for hardware created entropy to seed the software random number generator (SPRNG), after boot it will mix the system created entropy along with SPRNG entropy to increase the pool size and randomness.
If the CPU has RDRAND IPFire will get entropy from it.
I read AES-NI cpu support will help speed up VPN connections, I’m not sure if it will store it for other entropy uses.
I tend to forget things but a quick search turned up this about
/dev/random vs /dev/urandom
In the past with no RDRAND or EAS-NI cpu support I was able to increase my entropy by installing the Transmission service on IPFire, I shared the debian install DVD’s for both 32 and 64 bit along with the various IPFire installers, I still share them but not for the entropy anymore.
I added the ubuild.it TrueRNG3 USB device to my system for entropy, the waiting for entropy to boot is gone, it just works and flawless so far, it may deserve a mention in the wiki?
As mentionned here by Michael, AES-NI is not related to entropy but to encryption.
The second point is related to external HWRNG like TrueRNG3: I’ve read somewhere in this forum or in the blog that it was not recommended but I cannot find the page anymore… So I would not mention it yet
I’ll add the info about boot time (proposed by @anon42188109 as well) and about the certificate creation time.
I only recall people making comments about the American flag on it, likely they were wondering if it was back doored or something from the U.S. government I would guess? I don’t recall the not recommended part.
While I don’t know if it has been tampered with I had read even if they did it would likely have no or little affect since linux is still mixing entropy from other sources.
I believe I read that somewhere over the RDRand and Linus Torvalds debate?
I looked over the Wiki on entropy again, it is lacking, I’m glad to see you are giving it some updates!
LOL, mostly Americans commented on this because you don’t trust your government. Probably the right thing to do…
So to mess up this conversation even more, I would like to say: Ignore the graph.
I wanted to get rid of it for a while now because it is useless and it distracts people. Your system is not going to be any more secure if you have more entropy or less.
This is because of some recent changes in the Linux kernel and how they deal with entropy there. Mainly the development was driven by virtual systems that have no way to generate a good amount of entropy at all. There are no key strokes, no hard drives, no network packets that could be timed - there isn’t even a real timer that can be trusted.
So what to do in such a situation?
The answer is: It cannot be solved. So the kernel developers improved the pseudo RNG in the kernel in such a way that it is cryptographically secure and use that as a source for everything - including key material.
This CSPRNG (cryptographically secure pseudo random number generator) is seeded once when the system is booting up. Before that, no application can draw any entropy from it and that can sometimes be seen because we stop the boot process and wait until enough entropy is there for an initial seed.
If you have a system with RDRAND, you won’t see this process because RDRAND or RDSEED will be used to seed it. Occasionally more entropy from RDRAND will be mixed into the pool, but that isn’t strictly necessary.
So in short: A hardware random number generator isn’t being used much any more. Applications should use the kernel’s CSPRNG and nothing else. Coming back to the flag: What would you trust another device on its own? The kernel mixes various sources of entropy and the code has been audited and tested very very very well since it is deployed literally everywhere.
I would say: Save your money on the hardware and donate it to us
Yes that is you generating entropy You can add a virtual RNG to the virtual machine on Proxmox which gives the virtual machine access to the host’s pool. By default that is the host kernel’s CSPRNG.
Thanks much for this info
“can add a virtual RNG to the virtual machine”
I am experienced in VMWare, Linux KVM and did know that, cool
As for us Americans not trusting our government, indeed no so much, not sure any can be these days anyway LoL. The US government can do a lot secretively, doubt they could do any nefarious stuff like that easily with all the bureaucracy and effort takes without getting known somehow ? but then, still do not trust them.
