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

15.0.0.0.9 Review

#1
  • 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
#2

Reported password length limit upstream:

1 Like
#3

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?

#4

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

#5

FTR

DNS leaktests: PASS

whonixcheck–with-leaktests : PASS

anon-gw/ws-leaktests packages: PASS

#6

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

#7

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
#8

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

1 Like
#9

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
#10

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.

#11

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.)

#12

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?

#13

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
#14

Reported interest in seeing tomb patches backported to Debian stable:

1 Like
#15

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

#16

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

#17

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
#18

Another problem successfully resolved:

Troubleshooting is ongoing:

2 Likes
#19

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

1 Like