Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND

From Kicksecure
< Dev
Jump to navigation Jump to search

Technical Design Documentation about Entropy

Introduction[edit]

The Linux Kernel man pagearchive.org says: "[...] /dev/random should be suitable for uses that need very high quality randomness [...]".

Quoted from the riseup.net page about entropyarchive.org: "[...] entropy-estimation is a black-art and not very well understood [...]".

While it would be good to be cautions, i.e. learning about the entropy quality in Virtual Machines and if required learning about methods to improve it, it is not a critical problem. Successful entropy estimation attacks have never been reported for any software.

User space (not kernel space) entropy failures:

Kernel entropy failures:

We performed a large-scale study of RSA and DSA cryptographic keys in use on the Internet and discovered that significant numbers of keys are insecure due to insufficient randomness.

Most critically, we found that the Linux random number generator can produce predictable output at boot under certain conditions,

Every software package we examined relies on /dev/urandom to generate cryptographic keys; however, we find that Linux’s random number generator (RNG) can exhibit a boot-time entropy hole that causes urandom to produce deterministic output under conditions likely to occur in headless and embedded devices

Interesting:

https://blog.cr.yp.to/20140205-entropy.htmlarchive.org

https://cseweb.ucsd.edu/~nadiah/archive.org

Quality[edit]

As long as one entropy source of many is high quality, this foils attempts by adversaries to predict output and rescues the RNG. [1]

RDRAND[edit]

Debian trusts RDRAND by default since Debian buster. Quote https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#entropy-starvationarchive.org

Due to systemd needing entropy during boot and the kernel treating such calls as blocking when available entropy is low, the system may hang for minutes to hours until the randomness subsystem is sufficiently initialized (random: crng init done). For amd64 systems supporting the RDRAND instruction this issue is avoided by the Debian kernel using this instruction by default (CONFIG_RANDOM_TRUST_CPU).

Non-amd64 systems and some types of virtual machines need to provide a different source of entropy to continue fast booting. haveged has been chosen for this within the Debian Installer project and may be a valid option if hardware entropy is not available on the system. On virtual machines consider forwarding entropy from the host to the VMs via virtio_rng.

If you read this after upgrading a remote system to buster, ping the system on the network continuously as this adds entropy to the randomness pool and the system will eventually be reachable by ssh again.

See the wikiarchive.org and DLange's overview of the issuearchive.org for other options.

security-miscarchive.org (installed by default in Kicksecure) distrusts the CPU for initial entropy at boot as it is not possible to audit, may contain a bug, weaknesses or a backdoor.

RDRAND should not be trusted.

https://www.phoronix.com/news/Linux-RdRand-Sanity-Checkarchive.org

https://www.phoronix.com/review/crosstalk-srbds-vulnerabilityarchive.org

In T727#16542archive.org, @HulaHoopWhonix wrote:

Playing devil's advocate here: Ted Ts'o [0] expresses strong skepticism about the efficacy of RNGs that rely on CPU jitter. summary: CPU jitter may not be random as thought to someone who designed the CPU cache and know how its internals "tick" [1]. So while these RNGs may not harm, another solution for RNG-less platforms may be a good idea.

[0] He's the main developer behind Linux's RNG and staunchly resisted relying only on Intel's RDRAND. His opinions carry weight with good reason.

[1] https://lwn.net/Articles/586427/archive.org

It may be that there is some very complex state which is hidden inside the the CPU execution pipeline, the L1 cache, etc., etc. But just because *you* can't figure it out, and just because *I* can't figure it out doesn't mean that it is ipso facto something which a really bright NSA analyst working in Fort Meade can't figure out. (Or heck, a really clever Intel engineer who has full visibility into the internal design of an Intel CPU....)

Write to /dev/random[edit]

Quote Wikipedia:

This could use a better source. While the contents can be confirmed this write-up is good.

It is also possible to write to /dev/random. This allows any user to mix random data into the pool. Non-random data is harmless, because only a privileged user can issue the ioctl needed to increase the entropy estimate. The current amount of entropy and the size of the Linux kernel entropy pool, both measured in bits, are available in /proc/sys/kernel/random/ and can be displayed by the command cat /proc/sys/kernel/random/entropy_avail and cat /proc/sys/kernel/random/poolsize respectively.

/dev/random by default is world-writable. Unprivileged users can write to it. If that was considered insecure /dev/random would not be world-writable by default. In other words, nothing written to /dev/random can lower the entropy quality of the system. This would only be risky if the entropy was credited using ioctl.

Related: rndaddentropy - An RNDADDENTROPY ioctl wrapper

risks writing to /dev/random[edit]

Patrick:

Mixing even fully compromised entropy sources is considered secure in the current Linux kernel implementation. Though, D. J. Bernstein disagrees with that.archive.org

Quotearchive.org 3hhharchive.org:

Bernstein assumes that you have entropy sources that you trust and some that are less trustworthy. If that's true, his statement on "stick with the single one you trust and ditch all other input" is correct (and you only need 256 bits or so exactly once).

However the Linux guys assume that you don't want to ultimately trust any of the entropy sources available to you (or are too uninformed to make the decision) and thus live with a few potential attacks.

I believe the latter is a more realisitic view atm (Linux runs on many "suboptimal" devices).

If you build your own hardware RNG and use that, Bernstein's view is more accurate.

https://forums.whonix.org/t/risks-of-writing-to-dev-random-crediting-entropy-rndaddentropy-related-to-untrusted-root/8976archive.org

Credit Entropy[edit]

refers to this as "credit the entropy" vs "not credit the entropy".

Quote https://man7.org/linux/man-pages/man4/random.4.htmlarchive.org

ioctl

RNDADDTOENTCNT Increment or decrement the entropy count of the input pool by the value pointed to by the argument.

RNDADDENTROPY

Add some additional entropy to the input pool, incrementing the entropy count. This differs from writing to /dev/random or /dev/urandom, which only adds some data but does not increment the entropy count. The following structure is used: 

struct rand_pool_info {
    int    entropy_count;
    int    buf_size;
    __u32  buf[0];
};

Here entropy_count is the value added to (or subtracted from) the entropy count, and buf is the buffer of size buf_size which gets added to the entropy pool.

It is safer to improve the actual entropy but not credit it. The rationale here is if whatever is being developed here won't ever worsen entropy. The only requisite for that is that assumption that nothing written to /dev/random can worsen the entropy. If entropy was credited and the added entropy was flawed, the security could be actually worsened. Therefore the same strategy that systemd is implementing by default - adding entropy but not crediting it - is the safer way to implement new entropy generators. Better for entropy but no gain in performance.

If we added extra entropy and credited it: the process would be faster but less secure. I don't think we should make the process faster at the expense for higher risks. That would be possible but would require this solution to generate traction and peer review.

If we added extra entropy and credited it,

  • in best case: entropy quality increases
  • in worst case: we waste CPU cycles, increase lines of Kicksecure source code, waste time and accomplish no entropy quality increase but also no entropy quality degradation.

Goals:

  • Main goal: improve entropy quality
  • Improving boot time (credit entropy): non-goal
  • Not worsening boot time so that nobody wants to use Kicksecure anymore: goal
  • Price to pay: slightly increased boot time / system load

/dev/random vs. /dev/urandom[edit]

Update: this will improve in the future. See: https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/commit/?id=2ad310f93ec3d7062bdb73f06743aa56879a0a28archive.org

Still applies to Debian bullseye stable kernels:

https://github.com/smuellerDD/jitterentropy-rngd/issues/6#issuecomment-939110351archive.org

Viewpoint: "/dev/random is obsolete" has been deprecated. It's still available as a footnote. [2]

Better use /dev/random.

Here is what renown cryptographer Dr. Daniel J. Bernstein has to say on the matter. [3] The quote was cut to simplify things.

[...] but Linux /dev/urandom ([...]) spews predictable data [...]

Quote without cutting the parentheses. (Underline is mine. code is mine.)

[...] but Linux /dev/urandom (unlike Linux /dev/random) spews predictable data [...]

Oversimplified interpretation:

  • He's saying that /dev/random does not spew predictable data.
  • In other words, he's saying that /dev/random produces random data.
  • He's saying that /dev/urandom spews predictable data.

Quoting whole paragraph.

I'm not saying that /dev/urandom has a perfect API. It's disappointingly common for vendors to deploy devices where the randomness pool has never been initialized; BSD /dev/urandom catches this configuration bug by blocking, but Linux /dev/urandom (unlike Linux /dev/random) spews predictable data, causing (e.g.) the widespread RSA security failures documented on factorable.netarchive.org. But fixing this configuration bug has nothing to do with the /dev/random superstitions.

Interpretation:

  • He's saying that /dev/urandom spews predictable data if the randomness pool has never been initialized.

A randomness pool that has never been initialized is an issue in many cases:

  • first boot
  • inside virtual machines
  • first boot inside virtual machines
  • golden images without random seeds
  • golden images coming with published, shared (among all users of the golden image) random seeds

The issue of randomness pool initialization is well elaborated at systemd Random Seedsarchive.org.

Finally, I need to address what my interpretation is what he means by "superstitions". Quote:

the /dev/random superstitions.

Related paragraphs. Quote:

Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that

(1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but

(2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.).

For a cryptographer this doesn't even pass the laugh test.

Interpretation: He is only talking about people who think that /dev/random should always be used. Should always be considered more secure. Even in cases where randomness pool initialization is done. That is superstitious and I think that is a fair argument. The problem is, that it is non-trivial to know the status of randomness pool initialization. Therefore that is a rather theoretic consideration.

Quote systemd Random Seedsarchive.org:

(Strictly speaking there are more APIs, for example /dev/random, but these should not be used by almost any application and hence aren’t mentioned here.)

This could use some elaboration. Hence, asked, see systemd feature request: systemd.io/RANDOM_SEEDS - elaborate on /dev/randomarchive.org

My conclusion is:

  • Prefer using /dev/random whenever security is important such as for key generation.
  • /dev/random provides higher quality assurance than /dev/urandom. No conditionals.
    • /dev/urandom might be OK depending on randomness pool initialization.
    • /dev/random is OK either way.
  • This is specifically important at early boot when it's non-obvious if randomness pool initialization is done yet.
  • How to check the status of randomness pool initialization? Non-trivial.
  • Just make sure that /dev/random produces enough random data which is doable nowadays thanks to these software packages listed on this page.
  • /dev/urandom might be providing the same level of entropy quality as /dev/random does, but due to the previous point, for simplicity, there is no reason to use /dev/urandom.

My simplified conclusion is:

  • Use jitterentropy-rng kernel module, jitterentropy-rng user space daemon, haveged and whatnot.
  • And then simply use /dev/random.

Proponents of the viewpoint that "/dev/random is obsolete, use /dev/urandom, always" should explain:

  • Why Linux offers both, /dev/random and /dev/urandom and why if it is "really the same" isn't just a symlink from the one to the other.
  • Why Linux does not use the same code paths for /dev/random and /dev/urandom? Why have this distinction in the first place?

Kernel developer Theodore Y. Ts'o in 2019: https://lore.kernel.org/linux-ext4/20190915052242.GG19710@mit.edu/archive.org

The plain simple reality of entropy - Or how I learned to stop worrying and love urandom by Filippo Valsorda — @FiloSo, Cryptography and systems engineering at CloudFlare, Entropy_32c3_16-9.pdfarchive.org should according to Patrick Schleizer not be used to dismiss entropy quality considerations. The pdf mentions "The early boot problem", quote:

Very early at boot, /dev/urandom might not be seeded yet, predictable. This is a Linux shortcoming. The OS must save the entropy pool at poweroff. Your distribution probably does already.

Exactly such mechanisms need to be scrutinized. For example, Qubes OS does not persist random seed files (entropy) in App Qubes #1752archive.org, reported 2016, unfixed at time of writing October 2021.

Entropy Sources[edit]

Introduction[edit]

It has to be researched if they do work well inside Virtual Machines. Simply installing all of them may not be wise.

early-rng-init-tools[edit]

use kernel command line as a source of randomness[edit]

Introduction

[1] Kernel will use kernel command line as a source of randomness in any case - whether a random seed is added to kernel command line or not. Sources:

adding a random seed to kernel command line

Goal: see goal.

Design:

  • Do not credit entropy since this might be dangerous if something goes wrong.
  • Non-goal: Fixing performance related early entropy issue since there is none.
  • systemd unit file drop-in for systemd-random-seed.servicearchive.org by adding
    • ExecStartPost to refresh seed early at boot to avoid re-using the same one.
    • ExecStopPost to mix in new entropy that was collected since last boot.
  • add a randomseed= parameter to kernel command line
    • The kernel does not support a randomseed= parameter directly. But the kernel uses kernel command line as a source of entropy. The keyword randomseed= could be replaced with any other keyword. This is just for self-documenting purposes. I.e. by reading the web searching for and reading the scripts, clues are given why what is being done.

Similar to:

  • Adding a random seed to kernel command line would be similar to systemd-random-seed.servicearchive.org (enabled by systemd and Debian default) but happening earlier already at boot stage of initial ramdisk. systemd-random-seed.service by default also does not credit entropy.
  • Also similar to early-rng-init-tootls but without its potential security issues since not crediting entropy.

Disadvantages:

  • Does not work at first boot.
  • Does not work for live boot but no worse than too due to [1].

Advantages:

  • Same as systemd-random-seed.service but already available at boot stage initial ramdisk.

forum discussionarchive.org

timer_entropyd[edit]

sound based[edit]

randomsound[edit]

audio-entropyd[edit]

turbid - High-Entropy Symbol Generator[edit]

video-entropyd[edit]

TrueRand Based[edit]

clrngd - clock randomness gathering daemon[edit]

twuewand - a truerand algorithm for generating entropy[edit]

EGD - The Entropy Gathering Daemon[edit]

PRNGD - Pseudo Random Number Generator Daemon[edit]

jitter based[edit]

haveged[edit]

Haveged is an entropy gathering daemon.

Quoted from the haveged testing pagearchive.org: "[...] will behave similarly in a virtual environment is a more risky proposition [...] there have been reports of VM that implement the processor time stamp counter as a constant and there are known differences in cpuid operation in others. [...]"

Will haveged create sufficient entropy in VirtualBox? Luckily, haveged comes with tools to check the if the entropy it creates.

The README in the haveged source folder and the haveged websitearchive.org contains instructionsarchive.org for testing haveged.

Makes sense to test entropy while haveged is disabled. 

sudo service haveged stop

Get haveged sources and test. 

apt source haveged
cd haveged-*
./configure --enable-nistest
make check

## perhaps repeat
#make clean
#make check

Should say something like 

0 failed individual tests
PASS: nist/test.sh
==================
All 2 tests passed
==================
  • This was successfully tested in VirtualBox without haveged running.
  • This was successfully tested in VirtualBox with haveged running.
  • This was successfully tested in kvm without rng device and without haveged running.
  • This was successfully tested in kvm without rng device and with haveged running.
  • This was successfully tested in Qubes without haveged running. [4]
  • This was successfully tested in Qubes with haveged running.

Installed by default in Kicksecure.

jitterentropy[edit]

jitterentropy is a RNG designed in the spirit of haveged (using CPU timer jitter as entropy source) except it made up of a kernel module - mainlined since Linux 4.2 and a userspace daemon (jitterentropy-rngd*) to prevent /dev/random from blocking. The advantage of jitterentropy is by taking advantage of a loaded kernel module, it can ensure randomness is being collected before the CSPRNG is initialized. So, when CSPRNG initialization happens, we can ensure that it is properly seeded on first boot, minimizing the likelihood that exact keys will be created on distinct systems. This is something haveged can't provide, as it runs entirely in userspace.

It is a good alternative to haveged, especially for hypervisors that don't support virtio-RNG and so don't have access to entropy sources early during boot process. jitterentropy-rngd is now included in Debian Buster and has been available since Kicksecure 15. [5] [6]

Links:

Playing devil's advocate here: Ted Ts'o [7] expresses strong skepticism about the efficacy of RNGs that rely on CPU jitter. summary: CPU jitter may not be random as thought to someone who designed the CPU cache and know how its internals "tick" [8]. So while these RNGs may not harm, another solution for RNG-less platforms may be a good idea.

It may be that there is some very complex state which is hidden inside the the CPU execution pipeline, the L1 cache, etc., etc. But just because *you* can't figure it out, and just because *I* can't figure it out doesn't mean that it is ipso facto something which a really bright NSA analyst working in Fort Meade can't figure out. (Or heck, a really clever Intel engineer who has full visibility into the internal design of an Intel CPU....)

kernel module added (Kicksecure 15.0.0.7.2) and above:

Combining Multiple Jitter Based Entropy Gathering Daemons[edit]

https://github.com/smuellerDD/jitterentropy-library/issues/16archive.org

Motherboard Integrated[edit]

"such as some Intel/AMD/VIA chipsets"

rng-tools[edit]

In Debian.archive.org

Requires a Hardware RNG device. Will result in a failed systemd unit file if none is available. Can be hacked to use it's own entropy pool to gain entropyarchive.org, but this is probably a bad idea. [9]

Useful nonetheless to install on the host for those who are lucky to have a hardware random device? RDRAND can be found on every AMD64 processor since 2015 [10]. Some VIA processors and the Raspberry Pi also have RNG. [11]

rng-tools-debian[edit]

In Debian.archive.org

rng-tools5[edit]

In Debian.archive.org

Remote Server Based[edit]

GUChaos[edit]

pollinate[edit]

Linux kernel GCC Plugins[edit]

latent_entropy[edit]

Linux has the latent_entropy GCC plugin to gather more entropy.

Quote https://github.com/torvalds/linux/blob/master/scripts/gcc-plugins/Kconfigarchive.org

By saying Y here the kernel will instrument some kernel code to extract some entropy from both original and artificially created program state. This will help especially embedded systems where there is little 'natural' source of entropy normally. The cost is some slowdown of the boot process (about 0.5%) and fork and irq processing. Note that entropy extracted this way is not cryptographically secure!

CONFIG_GCC_PLUGIN_LATENT_ENTROPY is disabled by default in the Debian kernel but hardened-kernelarchive.org enables it.

The linux-hardenedarchive.org kernel patch improves latent_entropy by adding a extra_latent_entropy boot parameter [12] which security-misc enables.

virtio-rng[edit]

virtio-rng

Hardware Entropy Keys[edit]

Entropy Key[edit]

Entropy Keyarchive.org; Hardware not fully open source. Some resources say, it is okay as an additional source of entropy. Where to add it? Since Kicksecure depends on a host operating system, the Kicksecure and the Kicksecure, where it does make most sense to add it? Perhaps adding it to the host and using a entropy broker could be the most effective method. Better than buying three entropy keys.

OneRNG[edit]

OneRNGarchive.org; Hardware and Firmware fully open source. Firmware is cryptographically signed to ensure it hasn't been tampered with. Board has a removable tin RF Shield so you can verify the circuits match the diagrams provided by the manufacturer. Fully reprogrammable with manufacturer provided software+cable (must be bought separately). Where to add it? Where it does make most sense to add it? Perhaps adding it to the host and using a entropy broker could be the most effective method.

List[edit]

rndaddentropy - An RNDADDENTROPY ioctl wrapper[edit]

Software[edit]

$ENTROPY_GENERATOR | rndaddentropy

Quote rndaddentropy man pagearchive.org:

rndaddentropy is used to pipe entropy directly into Linux's primary entropy pool. This requires superuser privileges. Adding entropy directly to the primary entropy pool can be very dangerous, a predictable entropy increases the predictability of resulting data from /dev/random and /dev/urandom. Be sure the entropy is generated from a truly random source, and is properly debiased.

Opinion[edit]

Probably not needed and hard to use in a secure way. See #Write to /dev/random and #Credit Entropy.

Debiasing and Whitening[edit]

https://github.com/smuellerDD/jitterentropy-library/issues/16#issuecomment-581901851archive.org

Early Entropy Issue[edit]

TODO: update

This is described here: https://web.archive.org/web/20191031233802/https://systemd.io/RANDOM_SEEDS.htmlarchive.org

I don't think there's a fragile time window. We're distrusting RDRAND already. Kernel will block /dev/random until ready and of sufficient quality.

Any new entropy gathering daemons could block booting until systemd sysinit.target or something even earlier is done. 

Kicksecure / Kicksecure VMs currently also do not have a slow boot issue due to entropy starvation.

VirtualBox Bug Reports[edit]

Entropy Broker[edit]

Entropy Broker is an infrastructure for distributing cryptographically secure random numbers (entropy data) from one or more servers to one or more clients.

Entropy Tests[edit]

ent[edit]

sudo apt install ent

ent file_name

rngtest[edit]

sudo apt install rng-tools5

cat file_name | rngtest

dieharder[edit]

sudo apt install dieharder

dieharder -a -f file_name

PractRand[edit]

https://pracrand.sourceforge.netarchive.org

Implementation[edit]

Once we can come up with a design for a new entropy gathering daemon (and perhaps a proof of concept in script language / rapid prototype) 0xsirusarchive.org might help to implement the performance critical part in C programming language depending on complexity.

Goal[edit]

Assumption is that any source of randomness could be (sometimes) flawed (weak / predictable / broken / compromised) (in some situations). Such as either in VMs and/or n the host.

Therefore the goal was established to - simplified - "make use of as many sources of entropy as possible".

Ideally, sources of randomness should also be coming from different devices.

CPU is already being used as a source of entropy by haveged and jitterentropy-rng. That's two implementations using the same source using the same device. Adding more entropy generation daemons that are based on CPU - or even worse - based on jitter - is therefore undesirable.

It would be better to tap into other entropy sources such as from noise generated from audio, video, etc. if we can verify these to be good sources of entropy. By implementing that, even if one source of randomness (retrospectively) turns out to be flawed, quality of system entropy should still be excellent.

Resources[edit]

Comics[edit]

Footnotes[edit]

  1. ↑ Peter Gutmann of secure erasure fame https://www.metzdowd.com/pipermail/cryptography/2019-September/035329.htmlarchive.org
  2. ↑ The following viewpoint "/dev/random is obsolete" has been deprecated.

    This debate comes from a misconception by the Linux manual writer.

    https://web.archive.org/web/20230530100652/https://pthree.org/2014/07/21/the-linux-random-number-generator/archive.org

    The fact is both APIs use the same CSPRNG. The issue happens when the randomness pool has not been properly initialized and entropy is requested early at boot. Otherwise the blocking behavior of /dev/random during normal system running is an annoying bug than a useful safety feature. A well seeded pool should be able to provide sufficient/endless randomness from a single seed.

    https://news.ycombinator.com/item?id=11561340archive.org Comments by tptacek

    https://www.2uo.de/myths-about-urandomarchive.org

    There is no concept of entropy being used up when urandom is used unlike random that nonsensically calculates left over entropy and blocks despite a healthily initialized pool.


    https://unix.stackexchange.com/questions/94206/how-to-determine-which-processes-are-using-how-much-entropy-from-dev-urandomarchive.org

    Therefore rate limiting virtio-rng is unnecessary when using urandom as a backend.

    Here is what renown cryptographer Dr. Daniel J. Bernstein has to say on the matter:

    https://www.mail-archive.com/cryptography@randombit.net/msg04763.htmlarchive.org

    Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that

    (1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but

    (2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.).

    For a cryptographer this doesn't even pass the laugh test.

    I'm not saying that /dev/urandom has a perfect API. It's disappointingly common for vendors to deploy devices where the randomness pool has never been initialized; BSD /dev/urandom catches this configuration bug by blocking, but Linux /dev/urandom (unlike Linux /dev/random) spews predictable data, causing (e.g.) the widespread RSA security failures documented on factorable.netarchive.org. But fixing this configuration bug has nothing to do with the /dev/random superstitions.

  3. ↑ https://www.mail-archive.com/cryptography@randombit.net/msg04763.htmlarchive.org
  4. ↑ https://phabricator.whonix.org/T32archive.org
  5. ↑ https://phabricator.whonix.org/T817archive.org
  6. ↑ https://phabricator.whonix.org/T727archive.org
  7. ↑ He's the main developer behind Linux's RNG and staunchly resisted relying only on Intel's RDRAND. His opinions carry weight with good reason.
  8. ↑ https://lwn.net/Articles/586427/archive.org
  9. ↑ 
    Setting up rng-tools (2-unofficial-mt.14-1+b2) ...
Job for rng-tools.service failed because the control process exited with error code.
See "systemctl status rng-tools.service" and "journalctl -xe" for details.
invoke-rc.d: initscript rng-tools, action "start" failed.
\u25cf rng-tools.service
   Loaded: loaded (/etc/init.d/rng-tools; generated)
   Active: failed (Result: exit-code) since Fri 2020-01-31 10:56:20 UTC; 7ms ago
     Docs: man:systemd-sysv-generator(8)
  Process: 32118 ExecStart=/etc/init.d/rng-tools start (code=exited, status=1/FAILURE)

Jan 31 10:56:20 host systemd[1]: Starting rng-tools.service...
Jan 31 10:56:20 host rng-tools[32118]: Starting Hardware RNG entropy gatherer daemon: (Hardware RNG device inode not found)
Jan 31 10:56:20 host rng-tools[32118]: /etc/init.d/rng-tools: Cannot find a hardware RNG device to use.
Jan 31 10:56:20 host systemd[1]: rng-tools.service: Control process exited, code=exited, status=1/FAILURE
Jan 31 10:56:20 host systemd[1]: rng-tools.service: Failed with result 'exit-code'.
Jan 31 10:56:20 host systemd[1]: Failed to start rng-tools.service.
  10. ↑ https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdfarchive.org
  11. ↑ https://wiki.archlinux.org/index.php/Rng-toolsarchive.org
  12. ↑ https://github.com/anthraxx/linux-hardened/commit/0ca98c2ffe1ee5b4580c4d2aa797bc793164fc94archive.org

Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Dev/Entropy&oldid=81041"