9 ms·

VeraCrypt 1.24

200 points by h0ek 7y ago

CiPHPerCoder 7y ago
> 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]
2bitencryption 7y ago
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.
- Vadoff 7y ago
  https://medium.com/asecuritysite-when-bob-met-alice/the-fall-of-truecrypt-and-rise-of-veracrypt-44f910ed5162 https://medium.com/asecuritysite-when-bob-met-alice/the-fall...
  - acqq 7y ago
    No need to read the blog post, the "end" page is still reachable: http://truecrypt.sourceforge.net/ http://truecrypt.sourceforge.net/ and Wikipedia article is accurate: https://en.wikipedia.org/wiki/TrueCrypt https://en.wikipedia.org/wiki/TrueCrypt
- CiPHPerCoder 7y ago
  https://en.wikipedia.org/wiki/Paul_Le_Roux#TrueCrypt_release_and_controversy https://en.wikipedia.org/wiki/Paul_Le_Roux#TrueCrypt_release... 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.
  - acqq 7y ago
    > 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." Also: https://en.wikipedia.org/wiki/TrueCrypt#E4M_and_SecurStar_dispute https://en.wikipedia.org/wiki/TrueCrypt#E4M_and_SecurStar_di... Also: https://www.securstar.com/en/about-us.html https://www.securstar.com/en/about-us.html Also: https://groups.google.com/forum/?_escaped_fragment_=topic/alt.security.scramdisk/HYa8Wb_4acs https://groups.google.com/forum/?_escaped_fragment_=topic/al... And: https://groups.google.com/forum/?hl=en&_escaped_fragment_=msg/alt.security.scramdisk/AGZV0zWXDiE/qFNxCJJHq3oJ https://groups.google.com/forum/?hl=en&_escaped_fragment_=ms...
quietbritishjim 7y ago
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.
- vezycash 7y ago
  >Did you know that if you leave updating Windows too long the calculator just straight up stops working? Doesn't make sense to me. Cos on my laptops is running a 2015 version of windows 10. I refused to update it. Yet calculator still works there. It's possible that you're right and mine only works cos I did a lot of firewalling.
- mike503 7y ago
  I had that issue for a while but VC finally fixed it and haven’t seen any problems since.
  - quietbritishjim 7y ago
    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.
  - kijin 7y ago
    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.
makach 7y ago
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 7y ago
  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.
deleted 7y ago
[deleted]
therealmarv 7y ago
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 7y ago
  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 7y ago
    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.

200 points by h0ek 7y ago

> 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]

2bitencryption 7y ago

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.

Vadoff 7y ago
https://medium.com/asecuritysite-when-bob-met-alice/the-fall-of-truecrypt-and-rise-of-veracrypt-44f910ed5162 https://medium.com/asecuritysite-when-bob-met-alice/the-fall...
- acqq 7y ago
  No need to read the blog post, the "end" page is still reachable: http://truecrypt.sourceforge.net/ http://truecrypt.sourceforge.net/ and Wikipedia article is accurate: https://en.wikipedia.org/wiki/TrueCrypt https://en.wikipedia.org/wiki/TrueCrypt
CiPHPerCoder 7y ago
https://en.wikipedia.org/wiki/Paul_Le_Roux#TrueCrypt_release_and_controversy https://en.wikipedia.org/wiki/Paul_Le_Roux#TrueCrypt_release... 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.
- acqq 7y ago
  > 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." Also: https://en.wikipedia.org/wiki/TrueCrypt#E4M_and_SecurStar_dispute https://en.wikipedia.org/wiki/TrueCrypt#E4M_and_SecurStar_di... Also: https://www.securstar.com/en/about-us.html https://www.securstar.com/en/about-us.html Also: https://groups.google.com/forum/?_escaped_fragment_=topic/alt.security.scramdisk/HYa8Wb_4acs https://groups.google.com/forum/?_escaped_fragment_=topic/al... And: https://groups.google.com/forum/?hl=en&_escaped_fragment_=msg/alt.security.scramdisk/AGZV0zWXDiE/qFNxCJJHq3oJ https://groups.google.com/forum/?hl=en&_escaped_fragment_=ms...

quietbritishjim 7y ago

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.

vezycash 7y ago
>Did you know that if you leave updating Windows too long the calculator just straight up stops working? Doesn't make sense to me. Cos on my laptops is running a 2015 version of windows 10. I refused to update it. Yet calculator still works there. It's possible that you're right and mine only works cos I did a lot of firewalling.
mike503 7y ago
I had that issue for a while but VC finally fixed it and haven’t seen any problems since.
- quietbritishjim 7y ago
  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.
- kijin 7y ago
  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.

makach 7y ago

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

deleted 7y ago

[deleted]

therealmarv 7y ago

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