7 ms·

> 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

> 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_problem_with_dakarandtruerandtwuewand/ 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.

tux3 7y ago
You might be interested to know that Linux just merged a patch that fallbacks to jitter entropy when nothing else is available. See 50ee7529ec4500c88f8664560770a7a1b65db72b.
- cobbzilla 7y ago
  Does jitter entropy mitigate the need to install haveged [1] on systems with high entropy requirements? [1] https://issihosts.com/haveged/ https://issihosts.com/haveged/
  - tptacek 7y ago
    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.
    - cobbzilla 7y ago
      The most common is an internal CA server (certificate authority) that needs to generate many certs on demand.
      - tptacek 7y ago
        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.
        cobbzilla 7y ago
        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.
        morelisp 7y ago
        > Augmenting with haveged is pretty common So was snake oil.
        CiPHPerCoder 7y ago
        > Reading from `/dev/random` (true randomness) /dev/random doesn't provide "true randomness". /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. https://www.2uo.de/myths-about-urandom https://www.2uo.de/myths-about-urandom
        cobbzilla 7y ago
        It's complicated. https://www.mail-archive.com/cryptography@randombit.net/msg04771.html https://www.mail-archive.com/cryptography@randombit.net/msg0...
  - garaetjjte 7y ago
    No, it doesn't prevent /dev/random from blocking when estimated entropy runs out.
    - cobbzilla 7y ago
      Thank you. This is what I was asking.
kevinoid 7y ago
Using jitter as an entropy source also came up in the recent discussions around Linux getrandom(2) blocking: https://news.ycombinator.com/item?id=21152552 https://news.ycombinator.com/item?id=21152552 https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-basic https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f2dc2798b81531fd93a3b9b7c39da47ec689e55 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- CiPHPerCoder 7y ago
  Whether or not the kernel should be doing this is one issue, but VeraCrypt should be using whatever the kernel provides rather than rolling their own.
  - csande17 7y ago
    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.)
feanaro 7y ago
> My intuition is that this is dangerous and will likely result in security bugs in the future. Dangerous in what way? If it's properly mixed into the pool, it shouldn't make the pool more predictable.
- CiPHPerCoder 7y ago
  It can be dangerous in a lot of ways. Is JitterEntropy actually a CSPRNG or just a PRNG? Is it fork-safe? Is VeraCrypt's implementation secure?
  - feanaro 7y ago
    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.
CiPHPerCoder 7y ago
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 7y ago
  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 7y ago
    > 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.
    - 7y ago
woliveirajr 7y ago
That's why I like to use a keyfile. Unless it is badly coded, taking my 1kb of random bytes should help.
- CiPHPerCoder 7y ago
  TrueCrypt used CRC32 to mix keyfiles into the KDF. I never saw an entry in VeraCrypt's changelog addressing this deficit. I originally proposed BLAKE2 for this purpose on their issue tracker, circa 2014.
  - woliveirajr 7y ago
    It would be a good improvement. I'll try to check the source to see how it's done
  - justAnotherNET 7y ago
    Great point! I thought the same. You might need to explain this problem for the plebs among us, of which I’m totally not a member. ^/s
  - kozak 7y ago
    Does it mean that no matter the size of the key file, only the 32 bits of its CRC32 is being utilized?
    - CiPHPerCoder 7y ago
      https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_OCAP_final.pdf https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_O... Page 15 describes it in detail.
Kettur 7y ago
Linux kernel devs did exactly the same: using jitter entropy for randomness. If it is OK for kernel devs, then it should be OK for VC.
carlostheking 7y ago
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.
deleted 7y ago
[deleted]

tux3 7y ago

You might be interested to know that Linux just merged a patch that fallbacks to jitter entropy when nothing else is available. See 50ee7529ec4500c88f8664560770a7a1b65db72b.

cobbzilla 7y ago
Does jitter entropy mitigate the need to install haveged [1] on systems with high entropy requirements? [1] https://issihosts.com/haveged/ https://issihosts.com/haveged/
- tptacek 7y ago
  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.
  - cobbzilla 7y ago
    The most common is an internal CA server (certificate authority) that needs to generate many certs on demand.
    - tptacek 7y ago
      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.
      - cobbzilla 7y ago
        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.
        morelisp 7y ago
        > Augmenting with haveged is pretty common So was snake oil.
        CiPHPerCoder 7y ago
        > Reading from `/dev/random` (true randomness) /dev/random doesn't provide "true randomness". /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. https://www.2uo.de/myths-about-urandom https://www.2uo.de/myths-about-urandom
        cobbzilla 7y ago
        It's complicated. https://www.mail-archive.com/cryptography@randombit.net/msg04771.html https://www.mail-archive.com/cryptography@randombit.net/msg0...
- garaetjjte 7y ago
  No, it doesn't prevent /dev/random from blocking when estimated entropy runs out.
  - cobbzilla 7y ago
    Thank you. This is what I was asking.

kevinoid 7y ago

Using jitter as an entropy source also came up in the recent discussions around Linux getrandom(2) blocking: https://news.ycombinator.com/item?id=21152552 https://news.ycombinator.com/item?id=21152552 https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-basic https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f2dc2798b81531fd93a3b9b7c39da47ec689e55 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

CiPHPerCoder 7y ago
Whether or not the kernel should be doing this is one issue, but VeraCrypt should be using whatever the kernel provides rather than rolling their own.
- csande17 7y ago
  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.)

feanaro 7y ago

> My intuition is that this is dangerous and will likely result in security bugs in the future. Dangerous in what way? If it's properly mixed into the pool, it shouldn't make the pool more predictable.

CiPHPerCoder 7y ago
It can be dangerous in a lot of ways. Is JitterEntropy actually a CSPRNG or just a PRNG? Is it fork-safe? Is VeraCrypt's implementation secure?
- feanaro 7y ago
  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.

CiPHPerCoder 7y ago

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 7y ago
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 7y ago
  > 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.
  - 7y ago

woliveirajr 7y ago

That's why I like to use a keyfile. Unless it is badly coded, taking my 1kb of random bytes should help.

CiPHPerCoder 7y ago
TrueCrypt used CRC32 to mix keyfiles into the KDF. I never saw an entry in VeraCrypt's changelog addressing this deficit. I originally proposed BLAKE2 for this purpose on their issue tracker, circa 2014.
- woliveirajr 7y ago
  It would be a good improvement. I'll try to check the source to see how it's done
- justAnotherNET 7y ago
  Great point! I thought the same. You might need to explain this problem for the plebs among us, of which I’m totally not a member. ^/s
- kozak 7y ago
  Does it mean that no matter the size of the key file, only the 32 bits of its CRC32 is being utilized?
  - CiPHPerCoder 7y ago
    https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_OCAP_final.pdf https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_O... Page 15 describes it in detail.

Kettur 7y ago

Linux kernel devs did exactly the same: using jitter entropy for randomness. If it is OK for kernel devs, then it should be OK for VC.

carlostheking 7y ago

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.

deleted 7y ago

[deleted]