"Jitterentropy" vs CPU RDRAND in VeraCrypt 1.24 Veracrypt 1.24 just came out.  It uses a true random number generator based on hardware events; namely, on CPU timing jitter, or "Jitterentropy".

As an alternative to CPU RDRAND, I am a bit jittery about "Jitterentropy" in Veracrypt 1.24, and would like to hear some expert advice. The paper I just cited, by Stephan Müller, is very detailed.

Is Jittentropy a reliable cryptographic alternative to RDRAND in Veracrypt 1.24?
I too am perturbed ~~~.  A few relevant points that cause my own knees to wobble:-

A TRNG is a special cryptographic case in that it has information theoretic security.  And proving this requires accurate entropy estimation which is very difficult and pretty much still an open question for general sources. Killmann and Schindler,  Schürmann and Grassberger, Herrero-Collantes, Garcia-Escartin and I have shown this measurement to be intractable.  Even NIST acknowledges it.     Jitterentropy injects raw entropy into pools via a primitive LFSR (§3.1.3), and then Shannon entropy is measured via the school boy  log formula.  That’s not possible for raw general sources and it’s done on a flawed IID assumption.    $  \frac{d^2t}{di} $  is not a de-correlator (it's a low pass filter), and there was no permutation testing undertaken to prove the counter.

Stephan Müller is  indeed long.  I don’t like that.  The source of entropy should be plainly obvious to even the stupid and be there right up in your face.  Period. It should not take hundreds of lines of explanation and countless graphics. The entropy either comes from God, or doesn’t.    This is too complicated for me to inspire confidence that it’s not just a non OTP capable CSPRNG akin to /dev/urandom or a Modular Entropy Multiplication TRNG do-da :-



There are no obvious safety factors for entropy measurement.  I use a conservative 2 or 3 in my designs, but  Jitterentropy has none.  Lifting apparatus had a safety factor of 6, so it would seem prudent to have some factor if your life depends on it.  Even /dev/random has accommodation for one (although it's unwritten).

An (insurmountable?) fundamental problem with instrumentation of any OS kernel is the Observer Effect.  If you're hunting single bits of OS entropy, the signal to noise ratio is ~1:1.  A 0dB entropy signal is even worse than some of those really poor supposedly quantum TRNGs you find lurking in ePrint.

Finally, VeraCrypt’s random number generator documentation does not mention Jitterentropy as the source of it’s secrets.  They talk of:-

• Mouse movements 
• Keystrokes
• Mac OS X and Linux: Values generated by the built-in RNG (both /dev/random and/dev/urandom) 
• MS Windows only: MS Windows CryptoAPI (collected regularly at 500-ms interval) 
• MS Windows only: Network interface statistics (NETAPI32) 
• MS Windows only: Various Win32 handles, time variables, and counters (collected regularly at 500-ms interval) 


All the chatter in the VeraCrypt forums seems to concur.  We know unequivocally that         reading Java's System.nanoTime on a modern CPU generates true entropy, and that forms the basis of real time operating systems (RTOS).  Nullifying propagation delay by going to an expectation of $ x\delta $ mean execution times  in an RTOS does not necessarily allow you to quantify it in multi-tasking desktops.    But it’s very difficult to measure decisively. And the entropy rate is unstable, or at best meta stable. Especially within domain of all dedicated CPUs, IP CPU blocks and wacko software environments.

In management if you can't measure it, you can't manage it (Peter Drucker). There are other issues that perturb me as well, but this is getting waay too long.  I’m convinced that it’s a good CSPRNG, but remain unconvinced that it’s a TRNG, suffering the same basic mensuration problem that haveged and RDRAND/RDSEED do.