> 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.
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.
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.
> 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.
> 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 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.
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]
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.
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.
Maybe they need their own random number generator for the pre-boot decryption process? (Although come to think of it, I guess you only really need random numbers to generate the key when encrypting.)
What is a "high entropy requirement"? It is hard for me to come up with a secure design that somehow depends on having haveged installed; in practice, you should never be using it.
What about that environment needs "extra" entropy? You either have entropy or you don't; the volume of signings you do doesn't have anything to do with it.
Reading from `/dev/random` (true randomness) will block if there is insufficient system entropy available. You can read the currently available amount via `cat /proc/sys/kernel/random/entropy_avail`.
If you have an SLA that guarantees true randomness, and a certain response time or availability, you cannot really afford to block indefinitely while Linux builds up more entropy via its natural mechanisms.
Augmenting with haveged is pretty common, all it does is add more sources of randomness. I was hoping that jitter entropy (which seems kinda like the same thing) would alleviate the need to install one more package in these cases, but it's not clear. I will have to try it out sometime.
/dev/random and /dev/urandom provide the same kind of randomness. The difference is that, for 99.999% of developers, /dev/random blocks for no good reason.
All haveged does is pollute the kernel entropy pool to make /dev/random less unstable in production.
No, it's not. The old man page was incredibly confusing and misleading and has created a weird culture of fear around a simple issue.
What you care about is whether the RNG is securely seeded or not. Once it is, you don't care anymore. Think of an RNG like a stream cipher (which is what many of them are under the hood). Key AES-CTR with a 128 bit random key and run it to generate all the "random bytes" you will ever realistically use in any usage scenario. AES never "runs out of key". In the same way, a CSPRNG never "runs out of entropy".
We regularly re-key the system CSPRNG (by updating it, in the kernel, with "more entropy"), but not because entropy is depleted; rather, because it provides a measure of future security: if our machine is compromised, but only briefly, we don't want attackers to permanently predict the outputs of the RNG.
What you want are random/urandom interfaces that block at system startup until the RNG is seeded, and never again. What you do not want are userland CSPRNGs and CPSRNG "helpers"; those aren't solving real problems, have in the past introduced horrible security vulnerabilities, and perpetuate confusion about the security properties we're looking for.
Sign one X.509 certificate or ten million of them; the same initial secure dose of "entropy" will do just fine.
An archived email to a mailing list from one person in 2013 that can never be corrected or amended isn't the most reliable way to spread information about cryptography engineering.
What does Gutmann say in 2019 about /dev/urandom vs /dev/random?
Which of the two do JP Aumasson (author of Serious Cryptography and inventor of several cryptography algorithms used today, including BLAKE2 and SipHash), Dan Bernstein (Salsa20, ChaCha20, Poly1305, Curve25519, Ed25519, etc.), Matthew Green (professor associated with the TrueCrypt audit), et al. prefer in their own designs?
I can promise you the answer is /dev/urandom. Why do they prefer /dev/urandom? Because of the reasons outlined in the article I linked (which, unlike the mailing list post you linked, is occasionally updated with corrections).
It's not really that complicated: Use /dev/urandom.
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.
If you're on a recent Linux kernel, you can say "just use getrandom(2)" instead of "just use /dev/urandom", but the premise of the discussion is whether to use /dev/random or /dev/urandom not which of all possible options should be used.
It's worth maybe providing some detail as to why, so I will do so.
Entropy is a measure of unexpectedness present in a system. It is not a property of the data you have, but the physical system that generates some signal, called information content. In other words, a given password doesn't have entropy, but the process that generates it does. What this measures is how unexpected an outcome is on average. If it produces the same outcome every single time, it has no entropy because you know exactly what it will do. The best you can do is a 50% chance any bit will be 0 r 1 - you can't get more unexpected than this. Failure to achieve something close to this is called having biais and the result is that you must go directly to the NSA. Do not pass go, do not collect 200 dollars.
Then you have functions called deterministic random bit generators. These are deterministic - they behave the same way for a given set of input parameters. They also produce a stream of output that is sufficiently random-looking for cryptographic use. They can produce very large volumes of this - up to 2^44 blocks of entropy for example from NIST's CTR_DRBG before you have to abandon this stream and start again.
The entire sequence of random bits has exactly the same entropy as the seed that started it. I said data doesn't have entropy and I stick by it: the process has expanded beyond "sample environmental data" to "sample environmental data and shove it through a function good enough for cryptographic pseudorandomness then generate a nice big 2^44 128-bit blocks of data from that". The _entire output_ has the same entropy, as it is part of the same process.
I'm not saying the linux kernel does this exactly, more using it as a simple explanation for what I'm about to say - once you've got some entropy up to some nice amount like 256 bits you can use this as a seed for a deterministic random bit generator. What you get is a huge stream of randomness, almost certainly unique to you never to ever be seen again. And you only needed a very small amount of real entropy from hardware to get so much you will never run out.
Of course, there is nothing stopping you from "reseeding". You constantly have more entropy available and there's no harm mixing more into what you're generating (more entropy available comes from doing some more sampling of the environment and throwing this in).
Entropy is never used up. The randomness you get from /dev/random is not better. The randomness from a €1000 euro quantum random number generator is not better. Randomness doesn't rot like eggs and it is not known to the state of california to cause cancer. In fact, if you generate a key, it isn't random. It's known. It's static. What you get is some data that was generated with a certain amount of "surprisingness" in the process involved in getting it. If you repeat the process, you get more. There are obviously limits to the amount you get depending on the amount of data you ask for, because there are only finite possible outcomes, so it can only be on average so surprising. So you ask for enough that there are sufficiently many outcomes that if you could enumerate them all, you could also bruteforce AES by trying every possible key (we would not have enough energy to do this if we converted the entire mass of the earth to energy to power a classical quantum computer, let alone to do it before the heat death of the universe) - approximately speaking this will have more than enough entropy.
Throwing away those generated seeds because a single application has used them is extraordinarily wasteful and stupid because there is no need to wait. You can use that seed and the massive amount of "permutations" it generates in the DRBG for pretty much ever - I mean, unless of course you happen to need 2^44 or so 128-bit AES keys (that's over 2500 aes keys for everyone on earth). In that case, you can basically start generating them while you wait for another seed in your own time. You can probably nip to the beach or leisurely read a book. You'll still have enough time for your random process to give you another seed generated with a process of suitable entropy about a billion times over and then you've got so much cryptographic-quality random material it's like leaking out of your computer all over the floor!!!! Bits! Bits everywhere? Have you ever spilt rice? Kinda like that!
I endorse the above answer by Scott entirely, especially the bit about using /dev/urandom. This applies to any desktop or laptop computer system and probably most smartphones. The only time you can have problems is in getting the initial seed in the first place, and this only happens in embedded contexts with little variation in their runtime and no way to observe environmental noise and in this case /dev/urandom is preferred because getting more seeds is hard work and basically requires more time waiting for data to be seen. So /dev/urandom is objectively the better choice.
Perhaps you don't care, but OpenSSL's new random number generator is based on NIST's CTR_DRBG. It samples entropy from the environment using the approximations I have glossed overhere (it matches the NIST Special Publication's entropy estimation methods). They then generate a master source CTR_DRBG for the application context. Every SSL context object gets its own CTR_DRBG seeded from the master one, which is also valid to do! I told you! Randomness all over the kitchen floor like the bag of rice I just dropped so much of it you can't even vacuum it all up again how did it get in my washing exactly!!!????
Sorry, I mixed up the comment thread in which I was responding. I thought you were replying to the comment mentioning Linux adding a jitter entropy source during early boot in an effort to mitigate the lack of other entropy at that stage.
This is quite dishonest and truly perplexing. If you took 2 minutes to read the code and the docs, you'd know that the Jitter Entropy is NEVER the only source of entropy VeraCrypt uses but is instead added to other sources (/dev/urandom under Linux). Instead of just assuming things and jumping into conclusion, you'd better take your time and read. Also, wouldn't it be better if you created a 'ticket' or 'issue' in sourceforge / github if you think this is a very serious issue, or better, wouldn't t be better if you contacted the VeraCrypt team directly, instead of going ham like this. Truly dishonest.
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.
> It's pretty likely that Paul Le Roux was behind TrueCrypt.
He worked on E4M, but I can't imagine that he did TrueCrypt, given the stuff he did at these (post-E4M) times. It simply doesn't fit. Also, from Wikipedia link:
"Le Roux himself has denied developing TrueCrypt in a court hearing in March 2016, in which he also confirmed he had written E4M."
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, 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.
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.
It doesn’t fit with any of his skills. People think “oh, he knows cryptography, so he Must be a good candidate to be satoshi”. It’s not that simple, the perfect candidate is someone versed in the ecash literature as well as someone who can write an academic paper (even if lacking, the form is there).
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.
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.
One of my computers successfully updated from 1803 to 1809 without having to decrypt and re-encrypt the boot drive. So I thought the problem had been fixed, but it wasn't. I couldn't go from 1809 to 1903 without decrypting. I'll cross my fingers and try it again when 1909 comes out.
Another machine couldn't even update to 1809 without decrypting. After updating and re-encrypting, it refuses to mount any system favorite volumes. VeraCrypt is a mess. Or rather, Windows keeps breaking things.
I have the same problem at the moment.... I want to update my Windows 10 (from 1803 to 1903), but it is simply not possible. Everytime I want to update I get an error (0xc190012e)... I uninstalled VeraCrypt and decrypted all of my drives (Took quite a long time..), but no success.
Probably this does not even has to do with VeraCrypt: After a bit of research I found some posts. It seems like this error is caused by my SSD... I guess I have to reinstall my Windows.
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?
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.
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 :/
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.
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...
My intuition is that this is dangerous and will likely result in security bugs in the future.