News for hackers. Stuff that matters.
Re:VeraCrypt 1.24 by CiPHPerCoder on Monday October 07, 2019 @09:58PM (#21187933)
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.

Re:VeraCrypt 1.24 by zumdeibel on Tuesday October 08, 2019 @02:56PM (#21195765)
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...

Re:VeraCrypt 1.24 by raverbashing on Tuesday October 08, 2019 @02:28AM (#21189358)
Thanks, I saw this comment right after I posted mine.