
VeraCrypt 1.24 - h0ek
https://www.veracrypt.fr/en/Release%20Notes.html
======
CiPHPerCoder
> Use Hardware RNG based on CPU timing jitter "Jitterentropy" by Stephan
> Mueller as a good alternative to CPU RDRAND
> ([http://www.chronox.de/jent.html](http://www.chronox.de/jent.html))

I have never heard of Jitterentropy but it sounds vaguely like previous
attempts at RNGs.

/r/crypto had a good discussion about this topic a while ago:
[https://www.reddit.com/r/crypto/comments/9dln0v/whats_the_pr...](https://www.reddit.com/r/crypto/comments/9dln0v/whats_the_problem_with_dakarandtruerandtwuewand/)

My intuition is that this is dangerous and will likely result in security bugs
in the future.

~~~
CiPHPerCoder
From [https://github.com/smuellerDD/jitterentropy-
rngd](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](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.

~~~
bepvte
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/](http://www.issihosts.com/haveged/) Haveged
has existed since 2003 and has lots of documentation and discussion of its
randomness.

~~~
CiPHPerCoder
> 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.

~~~
raverbashing
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

~~~
CiPHPerCoder
See
[https://news.ycombinator.com/item?id=21187044](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...](https://paragonie.com/blog/2016/05/how-generate-
secure-random-numbers-in-various-programming-languages)

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.

~~~
zumdeibel
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](http://man7.org/linux/man-pages/man4/random.4.html)

[2]:
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=v5.3#n377)

[3]:
[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=v5.3#n770)

[4]:
[https://boringssl.googlesource.com/boringssl/+/refs/heads/ma...](https://boringssl.googlesource.com/boringssl/+/refs/heads/master/crypto/fipsmodule/rand/urandom.c)

------
2bitencryption
slightly off-topic, but could someone verify a memory I have regarding the
shutdown of TrueCrypt?

I vaguely remember after it was announced that the project was disbanded, that
there was one single commit from the authors whose only change was a textual
replacement of "United States" with "USA" everywhere it appeared.

Coming from the highly anonymous and secretive TrueCrypt group, this was
interpreted in this most scandalous possible way. I.e. the US govt was somehow
strongarming them. I'm not claiming that part is true, I'm just curious if my
memory is correct about the whole incident.

~~~
CiPHPerCoder
[https://en.wikipedia.org/wiki/Paul_Le_Roux#TrueCrypt_release...](https://en.wikipedia.org/wiki/Paul_Le_Roux#TrueCrypt_release_and_controversy)

[https://www.wired.com/story/mastermind-
excerpt/](https://www.wired.com/story/mastermind-excerpt/)

[https://magazine.atavist.com/the-
mastermind](https://magazine.atavist.com/the-mastermind)

It's pretty likely that Paul Le Roux was behind TrueCrypt.

~~~
mikorym
It's interesting that he is from Zimbabwe (then Rhodesia). Of course, his name
gives it away (that's why I checked). But what I wanted to say was something
else.

> he [liked] the video game Wing Commander [1]

Somewhere between 1990 and 1995 I recall that Windows PCs in South Africa
shipped with a games CD. You would get Ultima (immediately banned by your
parents), Wing Commander, Sea Wolf and other games and this would be your
staple for a while. When Warcraft 2 (or it may have been Starcraft) came out I
think it cost about R 350 (USD 90 in 1995) so you would need to be more picky
in the games you could buy than today. One should mention the rand's historic
dissonance with regard to the exchange rate and PPP, but whatever.

I remember buying some shitty Disney game for the same amount and regretting
it instantly (I played Warcraft 2 instead). It was not until 1999 that I saw
games "in bulk" with Tiberian Sun, ReVolt and a multitude of other games being
shared on DC.

[1]
[https://en.wikipedia.org/wiki/Paul_Le_Roux](https://en.wikipedia.org/wiki/Paul_Le_Roux),
edited for sensational language. Note that he had the console version, but I
am not sure which console that would be. The PS1 was the first major console
in South Africa (apart from "video games", i.e. famicon or NES clones) but I
may stand corrected.

~~~
6645throwaway
I’m reading the Atavist piece and noticed that he was extremely racist towards
Asians and yet two of his ex-wives were Asian. I wonder how he reconciled
that.

I feel really bad for his kids. When I studying in Asia, I met a few mixed-
race kids that had racist expat parents and they often had major identity
issues. For those that didn’t stay in the expat bubble, they would shun their
“Western side” and try to completely blend in with the locals.

~~~
mikorym
Well, where I come from, the racist people have a tendency to do that, so they
themselves have identity issues.

------
makach
After reading this thread, what alternatives do we have to VeraCrypt? Or
simply do we put our effort into improving the current version and help it
improve?

~~~
Strom
I don't think there are any decent alternatives to replace
TrueCrypt/VeraCrypt. There are some once you narrow the scope, like being fine
with linux-only etc. With the same scope as VeraCrypt there's nothing better.

Additionally TrueCrypt has been out there and well known for a long time. It
even had a pretty decent audit done. Even with its flaws this is a strong
foundation to build on. Any brand new undertaking is pretty much guaranteed to
have more flaws. Thus we should definitely focus on improving VeraCrypt. It
would also be easier to do an audit on just the changes from TrueCrypt to
VeraCrypt as opposed to a whole new program.

------
quietbritishjim
I really tried to use VeraCrypt on my main desktop Windows machine. But every
Windows 10 major update was a chore to get working with decrypting everything,
especially with GPT. (Did you know that if you leave updating Windows too long
the calculator just straight up stops working?) Eventually I caved in and
bought Windows Pro so I could use BitLocker (I'm aware of the problems of
using closed-source encryption software but it's good enough for me). Another
sad victory for Microsoft's anti-competitive practices.

~~~
mike503
I had that issue for a while but VC finally fixed it and haven’t seen any
problems since.

~~~
quietbritishjim
My computer had a problem (not uncommon apparently) that forced Windows to be
the default EUFI boot option. Admittedly this is perhaps more of a laptop
manufacturer bug than a problem from Microsoft.

I used a workaround suggested on the VeraCrypt forums: renaming the Windows
boot loader, replacing it with the VeraCrypt one, and pointing VeraCrypt at
the renamed option. This meant that any Windows update that updated the boot
loader would break the whole arrangement and to fix it I needed to boot from a
USB stick.

I think I most recently tried on version 1.22. It does sound like this version
has some relevant fixes though.

------
therealmarv
macOS Catalina related: Can Veracrypt read and write a completely Truecrypt
encrypted drive? Asking because new macOS will not support the latest
Truecrypt anymore because it is 32bit software :/

~~~
tmikaeld
I'd suggest using an encrypted volume file, that's what I currently do and am
using MacOS Catalina. So far, no problems.

The added advantage is that you can easily do backups of it.

~~~
therealmarv
I haver some legacy external drives which needs encryption (just for loss
protection and nobody can steal the content) and need to support multi OSes.
Otherwise I would agree.

