Hacker News Reader

Comment by CiPHPerCoder | Hacker News Reader

From https://github.com/smuellerDD/jitterentropy-rngd

> Using the Jitter RNG core, the rngd provides an entropy source that feeds into the Linux /dev/random device if its entropy runs low. It updates the /dev/random entropy estimator such that the newly provided entropy unblocks /dev/random.

This is a red flag. Entropy doesn't run low. https://www.2uo.de/myths-about-urandom

I'm calling it now: Don't use VeraCrypt.

They made a very questionable decision based on the sort of ignorance that leads people to use /dev/random and haveged rather than RtlGenRandom (Windows), getrandom(2) (new Linux), or /dev/urandom (old Linux).

Cryptography engineering requires care and this sort of ignorance tends to undermine secure implementations.

View on HN

Entropy running low is a frequent and actual problem for me on virtualized or headless servers serving https content. It slows everything, including ssh, to a halt.

You can see your current entropy level, which is probably high due to having a keyboard, with this command:

cat /proc/sys/kernel/random/entropy_avail

You can watch this number drain by reading from /dev/random continuously.

http://www.issihosts.com/haveged/ Haveged has existed since 2003 and has lots of documentation and discussion of its randomness.

> Entropy running low is a frequent and actual problem for me on virtualized or headless servers serving https content. It slows everything, including ssh, to a halt.

Entropy running low is not an actual problem. AES-CTR doesn't "run out of key".

If your OS's "entropy estimator" is producing small numbers and your userspace applications are using /dev/random, yes, that will degrade your performance. That's the actual problem.

The solution is for the developers of your software to stop using /dev/random, wholesale.

Saying that the actual problem is "entropy running low" is like saying "water is flammable". That might be true in extreme cases, but isn't in the general case.

You're right, except for an uninitialized entropy pool

Once the generator had been seeded (once), sure, read from urandom and don't worry.

The main issue is trying to read from it at boot time

See https://news.ycombinator.com/item?id=21187044

> If you're on an ancient Linux kernel, you can poll /dev/random until it's available if you're uncertain whether or not /dev/urandom has ever been seeded. Once /dev/random is available, don't use /dev/random, use /dev/urandom. This side-steps the "/dev/urandom never blocks" concern that people love to cite in their fearmongering. This is essentially what getrandom(2) does.

This is outlined here as well: https://paragonie.com/blog/2016/05/how-generate-secure-rando...

This is what randombytes_buf() does in libsodium on older Linux kernels.

This is actually the best of both worlds: Although /dev/urandom on Linux will happily give you predictable values if you try to read from it before the RNG has been seeded on first boot, once /dev/random is "ready" to be read from once, you know that the entropy pool powering /dev/urandom has been seeded. And then you can guarantee that /dev/urandom is secure and nonblocking henceforth.

If you can't just use getrandom(2), do the "poll /dev/random, then read /dev/urandom" dance and even the fearmonger's favorite issue to cite becomes a non-issue.

Thanks, I saw this comment right after I posted mine.

I don't think using poll on /dev/random is a good idea, here's why:

1. /proc/sys/kernel/random/read_wakeup_threshold is 64 by default [1,2], but the kernel only considers the pool initialized with >128 bits [3]. So in an early userspace you're likely to be reading from an uninitialized /dev/urandom after waking up from poll if you're not also checking the entropy count to be >128.

2. /dev/random could be a symlink to /dev/urandom, so the call to poll would return as soon as possible.

3. The system could only be providing /dev/urandom.

So if you're going to have to check the entropy count anyway, a less convoluted approach would be to repeatedly retrieve it via the RNDGETENTCNT ioctl [1] on a /dev/urandom file descriptor and sleeping while it hasn't reached >128 bits yet.

Don't take my word for the feasibility of this fallback method as I'm not a cryptographer or implementer of cryptographic interfaces. Instead, consider BoringSSL (Adam Langley et al.) that does almost the same in its /dev/urandom fallback. [4]

[1]: http://man7.org/linux/man-pages/man4/random.4.html

[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[3]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

[4]: https://boringssl.googlesource.com/boringssl/+/refs/heads/ma...

You are not observing the "problem" of entropy running low. Because it doesn't.

You are observing the misguided attempts of fixing this non-problem.

At the risk of getting downvoted for this, I urged caution against VeraCrypt in the past, because of the ties the company of its developer (IDRIX) has with the French government, lack of a history in cryptography before he took over VeraCrypt, and the overall possibility of nearness to the French security apparatus. People say that you can audit the code and compile it on your own, but who does that? Who checks the binaries?

To me with my overly vivid imagination, the fast forking of TrueCrypt to VeraCrypt looked like a hasty power grab by DGSE. Pure speculation, though.

what do you suggest as an encryption tool for full-drive encryption?

BitLocker is great, especially as it can also take advantage of a TPM to protect against evil maid attacks .

In contrast, VeraCrypt developers did not seem to understand what a TPM is when I tried to discuss the topic with them.

dubious - i would not trust bitlocker as it is not open source, and you cannot have it audited.

DGSE is not your opponent, they use rubber-hose decryption, works every time.

Entropy doesn't run low, but /dev/random does.

It's a valid statement in context, and using it as a dependency is not a red flag.

(Though VeraCrypt doesn't seem to get enough randomness to be safe if jitter fails, which is pretty worrying.)

What about https://github.com/nhorman/rng-tools ? Would this tool be problematic too?

What do you recommend that has similar functionality?

Currently, nothing. I used to recommend VeraCrypt for the exact set of use cases it satisfies.

Having an answer to this question is going to require research, which might take time.

How about just the previous older version of VeraCrypt for now?

The problem is that a design decision like this calls into question the competence of the developers, and therefore the safety of any modifications they've made in the past.

How about the original truecrypt? AFAIK it was audited and no bugs were found.

Bugs were found, actually.

https://blog.cryptographyengineering.com/2015/04/02/truecryp...

https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_O...

The keyfiles bug mentioned was previously disclosed against 7.0a: https://cyberside.net.ee/truecrypt/misc/truecrypt_7.0a-analy...

Reply on news.ycombinator.com