Entropy Quality

I am trying to confirm that it is safe to generate very high-importance private keys in Qubes Whonix. I’ve read every Wiki post and GitHub issue that Qubes/Whonix have on this topic (excellent work there Patrick) and I am close to being confident enough, but I want to be certain of a few more things.

I think the main sources of credited entropy are the kernel’s in-built “Linus Jitter Dance” [1][2], haveged and jitterentropy-rngd. There’s also some uncredited entropy from dom0’s getrandom(0) [3][4].

I personally would not generate a key in whonix-ws if CPU jitter was the only source of entropy. It’s only been around for a few years, and some people far smarter than me are strongly against it. Having the dom0 input mixed in would be enough to satisfy me, but I don’t think I quite understand the reseed mechanics in random.c [5].

  1. The most important thing that I need to confirm is that the new seed will be “linked to” the previous seed in some way. For example the new seed will be generated by hashing the previous seed with the new seed (or something to that effect). Otherwise the dom0 entropy will not be part of the crng seed after the first reseed takes place and everything will be reliant on jitter from there on out. I am struggling to confirm that from the code, but it’s possible that’s what it’s doing.

  2. I think it’s possible that the crng can end up being initially seeded only by CPU jitter in the case where the “Linus Jitter Dance” alone produces sufficient entropy for the initial seed. In this case systemd-random-seed service will run after the initial seed has taken place and therefore dom0’s entropy will not be included until the first reseed. Can you confirm that this could occur in theory and therefore we should wait some time for the first reseed to take place before generating a key (assuming we dont want to only rely on CPU jitter).

  3. In /usr/lib/qubes/init/qubes-random-seed.sh, the write is done to /dev/urandom, is this equivalent to writing to /dev/random or is there a reason urandom was chosen over random?

  4. Would you, Patrick, the developer of Qubes Whonix use Qubes Whonix to generate a very high-importance private key, or would you recommend importing from an external source (ignoring privacy concerns of mixing Whonix and an external source).

I have more questions, but I don’t want to make this first post too overwhelming.

Thanks.

[1] https://www.zx2c4.com/projects/linux-rng-5.17-5.18/inside-linux-kernel-rng-presentation-sept-13-2022.pdf
[2] random: try to actively add entropy rather than passively wait for it · torvalds/linux@50ee752 · GitHub
[3] https://github.com/QubesOS/qubes-core-admin/blob/main/qubes/vm/qubesvm.py#L2278
[4] https://github.com/QubesOS/qubes-core-admin/blob/main/qubes/utils.py#L138
[5] https://github.com/torvalds/linux/blob/master/drivers/char/random.c

Most of it is off-topic. Same as in Qubes Debian. Qubes-Whonix doesn’t worsen Qubes entropy.

Unspecific to Whonix.

This is the wrong place to ask about Qubes entropy.

I didn’t write that code so I can’t answer that.

Only commenting on /dev/urandom not reviewing full implementation:
Writing to /dev/urandom should be fine.

Quote random(4) — manpages — Debian bookworm — Debian Manpages

Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, […]

Yes I would do this before generating keys.

I don’t have privacy concerns about creating or copying random data into any VM to then feed it into the kernel.

Sorry Patrick, this post may have been off as a direct message to you. I acknowledge that these issues are not strictly related to Whonix, but given your level of activity in the Qubes and Whonix GitHub issues related to entropy I figured you were the best person for me to reach out to. I also figured that you would be in favor of more eyes reviewing all of this, given that most Qubes Whonix users will be generating high-importance keys.

Ideally I would reopen Improve entropy collection in VMs · Issue #673 · QubesOS/qubes-issues · GitHub with questions 1 and 2, but it took me a almost a day just to get signed up on GitHub and now that I am signed up my account is in manual verification limbo. Would you be able to relay these questions or link this post there?

My opinion is that even if the entropy issue is related to Qubes and not Whonix, users of Qubes Whonix should be notified on first boot.

You could post where it’s on-topic and then invite me to the discussion.

For example to any github ticket I replied such as Improve entropy collection in VMs · Issue #673 · QubesOS/qubes-issues · GitHub I am subscribed so I’ll get any messages. If time permits and I have something useful to contribute, I will.

Otherwise please post links to related discussions in the appropriate forum thread. For example if you open a discussion on the Qubes mailing list or forums you could post the link to that here: Moar Entropy Sources

Really no. Bad idea for me if I did that.

  • Easily confused as author instead of messenger by readers.
  • Easily confused my messages versus proxies messages.
  • Implies affiliation, review.
  • If I say yes now, it would require reasoning why saying no to others.

Please try to find other free or paid messengers.

created just now to ask Stephan Mueller: