[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

entropy /dev/random discussion - 15.0.0.0.9 Review

  • repos work with the new --redistribute flag

  • I noticed diceware was not included. Can I add it? It’s small 4MB

  • zulucrypt disappointingly does not work. Does not recognize the container password I set. I guess we have to wait for 2 more years and try again? :confused:

  • tomb fails when locking a newly created container with the keyfile. No useful info when diagnosing with the debug flag.


EDIT:
zulucrypt does work indeed. It just does not accept very long passphrases like a 20 word diceware passphrase. A workaround is to use a randomly generated 40+ character password and store it in an encrypted file that is then encrypted with (GPG?) with an easily memorable long diceware passphrase.

2 Likes

Reported password length limit upstream:

1 Like

HulaHoop via Whonix Forum:

  • repos work with the new --redistribute flag

Good.

  • I noticed diceware was not included. Can I add it? It’s small 4MB

Yes, whonix-workstation-packages-recommended-cli?

I can’t find it under https://github.com/Whonix/Whonix/tree/master/packages

FTR

DNS leaktests: PASS

whonixcheck–with-leaktests : PASS

anon-gw/ws-leaktests packages: PASS

HulaHoop via Whonix Forum:

I can’t find it under https://github.com/Whonix/Whonix/tree/master/packages

https://github.com/Whonix/anon-meta-packages/blob/master/debian/control#L229

Done:

I also added a utility called makepasswd that generates alphanumeric strings using /dev/urandom.

It seems like a usability upgrade to type:

makepasswd --chars 43

instead of:

head /dev/random | tr -dc A-Za-z0-9 | head -c 43 ; echo ''

But I must see if /dev/urandom is inferior to /dev/random before recommending.

EDIT:
These experts agree it is OK. Also in KVM’s situation, the virtio-rng is seeded by the host’s /dev/random

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

http://www.mail-archive.com/cryptography@randombit.net/msg04763.html

1 Like

ro-mode-init package still not installed by default in 15 but the live Whonix option works OK.

1 Like

Update:

The 100 character limit on passwords was a Qt bug that is now fixed in Zulucrypt git and will be released next month. What are the chances of getting Debian Buster to uplift this small patch? Should I even try?

1 Like

HulaHoop via Whonix Forum:

Update:

The 100 character limit on passwords was a Qt bug that is now fixed in Zulucrypt git and will be released next month. What are the chances of getting Debian Buster to uplift this small patch?

No idea. Debian testing frozen meaning it is supposed to be bug fixes
only and this looks like a bug fix. Might be possible.

HulaHoop via Whonix Forum:

ro-mode-init package still not installed by default in 15 […]
Expected. (No argument was put forward regarding installation of
ro-mode-init by default as far as I can remember.)

HulaHoop via Whonix Forum:

Done:

https://github.com/Whonix/anon-meta-packages/pull/20/commits/cc38f9ccb557d6e558481f0d4593943dc388bc71

I also added a utility called makepasswd that generates alphanumeric strings using /dev/urandom.

It seems like a usability upgrade to type:

makepasswd --chars 43

How does it compare against package pwgen? We already depend on that
one from whonix-workstation-packages-recommended-cli so one should be
removed?

But I must see if /dev/urandom is inferior to /dev/random before recommending.

That seems controversially debated. Some bits on this subject on
https://www.whonix.org/wiki/Dev/Entropy (which would also be a good
place to put any other research findings on entropy).

If /dev/urandom is the very same as /dev/random in some people’s
opinions then why isn’t the one a symlink to the other?

Done:

https://bugs.debian.org/927402


The only advantage I can think of is that a user doesn’t need to explicitly enable live-mode on each boot. Though this can be solved as you said anyhow. However no snapshots can be taken for a VM with read-only disk set while this is not the case for grub-live.

Even with the secure option pwgen -s it has been noted that it produces passwords with bias towards numbers and uppercase letters to make password checkers happy. It has been rejected as a CVE and therefore not fixed until now. This is not something I want in a truly randomly generated output:

https://bugs.debian.org/726578

CVE-2013-4443 Secure mode has bias towards numbers and uppercase letters

As for 4., as Steven remarked, this is done intentionally to placate
“password quality checkers”. Also, while allowing an all-lowercase password
2^-8 of the time does have negligibly more resilience against an exhaustive
attack, it is massively worse against attacks prevalent in the real world.
Thus, paying this small amount of entropy is well worth it.

A historical artifact made by the original implementors. DJB explains why the difference does not make sense.

The difference comes down to /dev/random blocking in an unproperly initialized entropy pool during boot while /dev/urandom does not. However once the system is up and running there should be no difference in practice because an RNG should be able to extend a good seed into an inexhaustible supply of random output. In any case this is unlikely on modern systems and now that we have virtio-rng and/org jitter-rng it becomes even less of a problem.

1 Like

Reported interest in seeing tomb patches backported to Debian stable:

1 Like

HulaHoop via Whonix Forum:

Done:

https://bugs.debian.org/927402


The only advantage I can think of is that a user doesn’t need to explicitly enable live-mode on each boot. Though this can be solved as you said anyhow. However no snapshots can be taken for a VM with read-only disk set while this is not the case for grub-live.

Even with the secure option pwgen -s it has been noted that it produces passwords with bias towards numbers and uppercase letters to make password checkers happy. It has been rejected as a CVE and therefore not fixed until now. This is not something I want in a truly randomly generated output:

https://bugs.debian.org/726578

CVE-2013-4443 Secure mode has bias towards numbers and uppercase letters

As for 4., as Steven remarked, this is done intentionally to placate
“password quality checkers”. Also, while allowing an all-lowercase password
2^-8 of the time does have negligibly more resilience against an exhaustive
attack, it is massively worse against attacks prevalent in the real world.
Thus, paying this small amount of entropy is well worth it.

A historical artifact made by the original implementors. DJB explains why the difference does not make sense.

The difference comes down to /dev/random blocking in an entropy starved system while /dev/urandom does not, but lack of entropy is not the fault of urandom but the system’s. In any case this is unlikely on modern systems and now that we have virtio-rng and/org jitter-rng it becomes even less of a problem.

https://en.wikipedia.org/wiki//dev/random reads as if it’s still a
thing. I don’t like the idea “if not enough entropy. /dev/urandom may
provide lower quality”. Even if very unlikely, it is yet more reason to
better error out than providing lower quality entropy. (Oops, exactly
happened during key generation.)

Crazy idea, should we rename /dev/urandom to /dev/urandom_original and
symlink /dev/random to /dev/urandom?

Still have to read again: https://www.2uo.de/myths-about-urandom

Two things:

  • Everything except GPG uses urandom
  • How does /dev/random reliably measure its own entropy anyhow?

It’s not as simple as symlinking . Rules have to be added to udev to avoid race conditions on boot and then there is something about that no longer being a working solution:

This is something that is better addressed upstream by the Linux project.


An interesting related technical discussion:
https://news.ycombinator.com/item?id=11561340

https://www.2uo.de/myths-about-urandom makes a good argument but I am not totally convinced.

The updated man page http://man7.org/linux/man-pages/man4/random.4.html contradicts itself in my understanding.

When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized.

Doesn’t sound great. Imagine some systemd or other bug where this goes unnoticed.

The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted.

  • Ok, so you say it’s legacy.
  • I see.

If this is of concern in your application, use getrandom(2) or /dev/random instead.

So not really legacy if /dev/random is still mentioned. Contradiction.

Linux 3.17 and later provides the simpler and safer getrandom(2) interface which requires no special files; see the getrandom(2) manual page for details.

-> password generator should use getrandom(2) rather than /dev/urandom since quote, “simpler and safer”.

The /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time; for these applications, getrandom(2) must be used instead, because it will block until the entropy pool is initialized.

BUGS

During early boot time, reads from /dev/urandom may return data prior to the entropy pool being initialized.

It is still sounds messy.

Quote https://www.2uo.de/myths-about-urandom

FreeBSD does the right thing: they don’t have the distinction between /dev/random and /dev/urandom, both are the same device. At startup /dev/random blocks once until enough starting entropy has been gathered. Then it won’t block ever again.

That sounds better.

But the discussion is too difficult to make a decision at the Whonix level. Not much we could do here except pointing people at these arguments, making arguments, discussing things upstream.

1 Like

Another problem successfully resolved:

Troubleshooting is ongoing:

2 Likes

Problem is now fixed, don;t know about the backporting yet.

1 Like

Re-reading this interesting article there’s a suggestion to use the rngd daemon that is meant to gather entropy from hw rngs to instead use urandom as its source and redirect output into random

If you really need to run the rngd service or if your application is blocked when asking for pseudo random numbers through the /dev/random device, there is a pseudo solution: you can configure the rngd service to get its entropy from the /dev/urandom device and feeds the /dev/random device.

Caution : This is a pseudo solution because you fill in the /dev/random device with data from the /dev/urandom device: the quality of the pseudo random numbers delivered by the /dev/random device is simply lower . This can be a real problem if these numbers produce SSH keys for example.

To be able to run the rngd service without hardware entropy source, create a copy of the rngd.service unit file: