[HN Gopher] VeraCrypt: Free open-source disk encryption for Wind...
       ___________________________________________________________________
        
       VeraCrypt: Free open-source disk encryption for Windows, Mac OS X,
       Linux
        
       Author : thunderbong
       Score  : 322 points
       Date   : 2023-10-02 02:11 UTC (20 hours ago)
        
 (HTM) web link (www.veracrypt.fr)
 (TXT) w3m dump (www.veracrypt.fr)
        
       | distract8901 wrote:
       | I actually really like VeraCrypt. Last time I used it was 5 or 6
       | years ago and the UI looked like something straight out of the
       | 90s, which is a good thing IMO.
        
       | mhogomchungu wrote:
       | If you are on Linux and prefer a Qt based GUI, then check out
       | zuluCrypt[1].
       | 
       | It can create PLAIN dm-crypt, LUKS, TrueCrypt and VeraCrypt
       | volumes.
       | 
       | It can unlock PLAIN dm-crypt, LUKS, TrueCrypt, VeraCrypt and
       | Bitlocker volumes.
       | 
       | [1] https://github.com/mhogomchungu/zuluCrypt
        
         | krylon wrote:
         | That is nice.
         | 
         | The big plus for VeraCrypt (and TrueCrypt before that),
         | however, is that it works on Windows, macOS, and Linux. If you
         | need an encrypted flash drive for sharing data between
         | different systems, it's the only option that I know of. Which
         | is unfortunate.
        
         | Grimburger wrote:
         | Not trying to diminish zulucrypt here but I really hope people
         | aren't choosing encryption programs based on the GUI framework
         | they use.
        
           | tetris11 wrote:
           | Well, veracrypt has a random seeding stage where you're
           | required to shake the mouse around to create randomness.
           | Problem is, that it only registers when the mouse is over the
           | actual tiny veracrypt window. Problem with that is, it tells
           | you that in some tiny bold text at the bottom. You can waste
           | literally an hour wondering why the randomness meter goes up
           | only sometimes. A better UI might fix that.
        
             | vlovich123 wrote:
             | Afaik that kind of entropy generation is silly on modern
             | machines. You should just call getrandom (or whatever the
             | equivalent is for the modern OS it's running on is) and be
             | done with it. Hand rolled entropy like this isn't necessary
             | anymore - the OSes have very high quality CSPRNGs baked in
             | natively and seeded directly from interrupts and other HW
             | entropy sources.
        
               | tetris11 wrote:
               | Good point. Is entropy built into the kernel, though?
               | Last time I checked this I had to manually enable it as a
               | system service, though this was a fair few years back.
        
               | Grimburger wrote:
               | > isn't necessary anymore
               | 
               | It also doesn't hurt if you hash it into or xor with
               | existing randomness, it will still be as strong as the
               | best source of entropy you have even if it's all 0's
               | being mixed in.
        
             | vore wrote:
             | A small UI improvement is not worth switching from a far
             | more tested and audited application. The UI might be worse,
             | but I wouldn't play dice with applications with critical
             | security requirements.
        
             | sandworm101 wrote:
             | You can make the window bigger, at least that can be done
             | on linux. Ive never tried veracrypt's gui on windows. I
             | very likely never will.
        
               | mxmlnkn wrote:
               | You can even click on the window, hold the mouse button
               | clicked and now all mouse movements, even outside the
               | window, register and increase the randomness meter.
        
           | speedgoose wrote:
           | I think putting some efforts in the user experience is
           | important. A better GUI may mean that more people will use
           | encryption.
           | 
           | Bitlocker and FireVault are very easy to use compared to
           | VeraCrypt or LUKS, and they are much more common. So many
           | Linux installations don't have disk encryption...
        
             | Grimburger wrote:
             | Most definitely, especially in FOSS which has a dearth of
             | good UX. But the point was more that this shouldn't be a
             | form-over-function moment, do that with something else like
             | a lounge purchase.
        
       | andersa wrote:
       | It's really annoying how none of these tools provide an easy way
       | to activate the properly fast, zero CPU overhead hardware-based
       | encryption that almost all modern SSDs can do, which also makes
       | it work properly with DirectStorage, etc.
       | 
       | The only one I'm aware of that can do it is Bitlocker, but the
       | setup is stupidly clunky for no reason (you even have to
       | reinstall windows to activate it - wtf).
       | 
       | A while back I used a tool to do it manually called sedutil but
       | it seems to be abandoned now and no longer works with modern
       | processors.
        
         | yomlica8 wrote:
         | Microsoft actually used the disk encryption scheme by default
         | in early versions of bitlocker. They had to backtrack because
         | the disk encryption implementations were found to often not
         | work at all!
        
         | ndiddy wrote:
         | SSD based encryption implementations are often highly insecure
         | and should never be used. Many drives don't even use the given
         | password to encrypt the data on the disk, meaning that flashing
         | the controller with a modified firmware with the password
         | validation patched out will let anyone decrypt the data without
         | needing to know the password. https://www.ieee-
         | security.org/TC/SP2019/papers/310.pdf
        
           | andersa wrote:
           | Well that's disappointing.
        
         | mschuster91 wrote:
         | > It's really annoying how none of these tools provide an easy
         | way to activate the properly fast, zero CPU overhead hardware-
         | based encryption that almost all modern SSDs can do, which also
         | makes it work properly with DirectStorage, etc.
         | 
         | Because the situation is similar to Dr. House: All disks lie.
         | An OS can't trust the quality of the encryption in modern SSDs,
         | there is no way short of dedicated hardware and firmware
         | reverse engineering to make sure it _actually_ encrypts the
         | data. And on top of that comes the issue with using the
         | supposedly  "secure" TPM for disk encryption, that in many
         | cases can simply be sniffed on the communication bus [1].
         | 
         | The only way a disk encryption solution can reasonably
         | guarantee security is if it either controls the whole stack
         | (such as Apple's FileVault using the T2 coprocessor on
         | Intel/built-in capabilities on M SoCs) or it does everything in
         | ring 0 inside the OS.
         | 
         | [1] https://pulsesecurity.co.nz/articles/TPM-sniffing
        
           | andersa wrote:
           | > Because the situation is similar to Dr. House: All disks
           | lie. An OS can't trust the quality of the encryption in
           | modern SSDs
           | 
           | Why is this the job of the OS? If we trust the SSD ourselves,
           | it should simply accept that and proceed using the API as
           | intended. For example, there's no reason to suspect anything
           | wrong with the latest Samsung SSDs, is there?
           | 
           | I've so far not understood the purpose of the TPM here. Why
           | can't the key be derived off a password entered during boot?
           | It's not necessary to involve a TPM at all.
           | 
           | It seems wild to even consider software encryption for the
           | whole disk at the bandwidth and iops modern SSDs are expected
           | to deliver.
        
             | mschuster91 wrote:
             | > Why is this the job of the OS? If we trust the SSD
             | ourselves, it should simply accept that and proceed using
             | the API as intended.
             | 
             | Because in the event of the crypto being only for show,
             | people might blame the software for not warning them.
             | 
             | > I've so far not understood the purpose of the TPM here.
             | Why can't the key be derived off a password entered during
             | boot?
             | 
             | The general idea behind using the TPM as a crypto HSM was
             | to provide at least a basic protection against simple disk
             | cloning, i.e. evil-maid attacks.
             | 
             | > It seems wild to even consider software encryption for
             | the whole disk at the bandwidth and iops modern SSDs are
             | expected to deliver.
             | 
             | CPUs are pretty fast these days at anything crypto, as
             | virtually all popular architectures have native AES
             | instructions.
        
             | akvadrako wrote:
             | The fact that no one else trusts it is good enough reason
             | not to use it. Crypto always starts out untrusted as there
             | is no way to prove it's secure. Only by standing the test
             | of time with widespread use does it gain at least a
             | relative advantage.
        
       | [deleted]
        
       | dividedbyzero wrote:
       | Last time I checked you had to disable System Integrity
       | Protection for it to work on Apple Silicon. Hard no for me, using
       | macOS's encrypted sparse bundle disk images now.
        
         | josephcsible wrote:
         | Why is disabling tivoization a hard no for you?
        
       | paulpauper wrote:
       | Just use Bitlocker . Despite being proprietary, it has withstood
       | court challenges, indicating no backdoor and much easier and
       | reliable than having to deal with utfi, firmware, compatibility,
       | and secure boot settings and other issues that may arise with
       | VeraCrypt when trying to encrypt the entire drive. Microsoft
       | makes it idiot proof to encrypt the drive. This is one of the few
       | instances in which the closed source option is better than open
       | source.
        
         | PappGaborSandor wrote:
         | [dead]
        
         | self_awareness wrote:
         | Bitlocker is Windows-only
        
           | villedespommes wrote:
           | You could use dislocker on Linux.
        
           | paulpauper wrote:
           | if the data is important enough just buy a laptop for
           | bitlocker only and then disconnect from the internet after
           | installing it.
        
         | 14 wrote:
         | As far as I see bitlocker isn't available for windows 10 home
         | edition. Unless there is something I am missing. That is why I
         | recently started looking at Veracrypt.
        
           | paulpauper wrote:
           | then buy pro. If the data is important enough, $100 is
           | trivial.
        
           | akvadrako wrote:
           | It's certainly on Windows 11 Home edition, but it isn't
           | called Bitlocker and has a less powerful GUI than the Pro
           | version.
        
             | MikusR wrote:
             | Only on supported hardware and your key is automatically
             | stored by Microsoft(but can be deleted)
        
               | k8sToGo wrote:
               | Last part only if you don't use the CLI.
        
         | loufe wrote:
         | Bitlocker requires an internet connection and Windows account.
         | Your backup key is sent to a microsoft server. Some people
         | would object to the government being able to request your key
         | from a server to search your encrypted files. That's exactly
         | what the government wants to happen.
        
           | k8sToGo wrote:
           | This is wrong. You can set it up with the command line tool
           | which neither sends your key nor do you need an account.
        
           | kogir wrote:
           | Bitlocker requires a Professional or greater license of
           | Windows, but needs neither an internet connection nor a
           | Microsoft account.
           | 
           | I have mine setup with TPM + PIN, and have archived the
           | recovery keys myself, not stored them with Microsoft.
        
           | paulpauper wrote:
           | I don't get it. my comment got heavily downvoted yet the
           | objection to my comment is wrong and also downvoted. So ...I
           | guess people don't like closed source, period.
        
       | tjrgergw wrote:
       | I've been using Truecrypt + syncthing since forever. Serious
       | question: why would I move to veracrypt? It seems just a risk
       | that something breaks.
        
         | AlphaCerium wrote:
         | Apparently Truecrypt has had development shut down in 2014 and
         | the devs are now telling people to migrate to Bitlocker as it
         | may be insecure: https://truecrypt.sourceforge.net/
        
           | tjrgergw wrote:
           | BitLocker - I'm not going to move to some windows-first
           | software.
        
       | faiD9Eet wrote:
       | Last time I checked the state of TrueCrypt it was 2014. There
       | used to be an audit saying "build chain is outdated, but software
       | is fine" and an hostile fork named VeraCrypt came to be,
       | incorporating a lot of new features. Some people where suspicious
       | how many bugs this code might have and whether to use VeraCrypt
       | at all.
       | 
       | How much trust do you put on VeraCrypt?
        
         | snailmailman wrote:
         | "Hostile fork"? Truecrypt was abandoned. The creator released a
         | "decrypt only" version and recommended all users switch to
         | different software.
         | 
         | From what I understand, Veracrypt just continued development
         | where Truecrypt left off
        
           | faiD9Eet wrote:
           | you are right, it was abandoned. I forgot about that.
           | 
           | From my understanding there never was an official successor,
           | that's why I consider VeraCrypt a fork.
        
       | SamFromSpace wrote:
       | Entirely tangential, but I recently participated in a CTF that
       | included a steganography challenge with a True/VeraCrypt volume
       | embedded inside a MP4 file. The MP4 file could be mounted just as
       | a normal VeraCrypt volume could be.
       | 
       | https://keyj.emphy.de/real-steganography-with-truecrypt/
        
         | yashoulda wrote:
         | [dead]
        
       | ransom1538 wrote:
       | Has anyone seen legal cases involving hidden partitions?
        
       | 8fingerlouie wrote:
       | I've used countless encryption "schemes" over the years, from
       | True/Vera-Crypt to encrypted sparse bundles/images, and none have
       | ever really felt right.
       | 
       | These days i tend to use Cryptomator[0] instead. It accomplishes
       | what none of the others could do, which is transparent encryption
       | across devices.
       | 
       | With Cryptomator, i simply create a vault somewhere in the cloud,
       | stuff data in it, and i can access it from my laptop, phone or
       | tablet, and not think much about it. It integrates into the
       | normal file browsing APIs, and doesn't get in the way.
       | 
       | Because it does "per file" encryption, it also doesn't need to
       | download a 20-100MB chunk from the cloud before decrypting, so
       | it's rather fast (depending on file size of course).
       | 
       | Cryptomator is also open source[1], and free on the desktop,
       | though the mobile apps costs a one time fee.
       | 
       | [0]: https://cryptomator.org/
       | 
       | [1]: https://github.com/cryptomator
        
         | arsome wrote:
         | I used to use similar per-file cloud solutions, but SyncThing
         | has been better in every way, especially if you already have a
         | server you want to sync to or can use as an encrypted endpoint.
        
           | 8fingerlouie wrote:
           | I've used syncthing sporadically over the years, but it has
           | had very bad iOS support whenever I've tried it.
           | 
           | Mobeus exists, but doesn't integrate into the files app, and
           | uses a lot of battery.
           | 
           | I also used Resilio Sync for years, but it appears to have
           | more or less died out.
           | 
           | So when it came to finding a replacement I settled on using
           | cloud native for synchronization, and simply put encryption
           | on top, and for that, Cryptomator is great.
        
             | [deleted]
        
           | geek_at wrote:
           | A few years ago I was in a Arma3 Milsim group that hosted
           | their own server.
           | 
           | Back then there was no automated way to sync plugins so we
           | installed syncthing and told all users to install it too.
           | 
           | We put like 50gigabytes worth of addons on syncthing and the
           | users were so much happier because since 50+ people were
           | using this syncthing connection, everyone could download with
           | full speed from the others as in contrast to the 100mbit/sec
           | bandwith of the HTTP server we formerly used.
           | 
           | And nobody had to care about checking versions anymore, the
           | syncthing folder was directly synced into the Arma3 plugin
           | directory
        
             | jetbalsa wrote:
             | That is not a bad model if you completely trust the server
             | owners. I feel there are more secure ways, but I suspect if
             | a Arma3 server wanted to infect a machine with a bad mod
             | they could. so the threat vectors are the same really.
        
           | mdhen wrote:
           | I use CryFS combined with SyncThing, perfect solution for my
           | needs. Have it set up on linux and android.
        
         | 1696239517 wrote:
         | Looks very similar to the 'Crypt' remote offered by Rclone[0]
         | 
         | I use it to store 'per file' encrypted data on Dropbox. (I also
         | keep a restic repository on there)
         | 
         | [0]: https://rclone.org/crypt/
        
           | Saris wrote:
           | Rclone doesn't work too well on mobile though, which is where
           | cryptomator is really nice.
        
           | 8fingerlouie wrote:
           | I have used rclone with crypt in the past, and it works well,
           | but doesn't easily lend itself to being used from mobile
           | devices, which is what led me to Cryptomator in the first
           | place.
           | 
           | I don't want to rely on having a server running at home,
           | which i can then connect to via VPN, in order to download
           | encrypted stuff from the cloud. With Cryptomator i can simply
           | download from the cloud and decrypt locally.
        
         | akvadrako wrote:
         | Gocryptfs is another alternative in the same vein. I've
         | switched to it from Cryptomator as it has better Android
         | support and is more ergonomic on the command line.
        
           | alwyn wrote:
           | What I haven't found a solution for, is being able to
           | synchronise and open a gocryptfs with cloud sync on Android.
           | Dropbox/Drive/pCloud folders aren't directly accessible or
           | mounted in Android. One work-around could be to export a zip
           | of the folder from Dropbox/whatever, then extract and open
           | that, but that's one-way.
           | 
           | Do you have a solution for this?
        
             | akvadrako wrote:
             | I use syncthing for this. But yeah it isnt ideal.
        
             | chuckufarley wrote:
             | Likely won't be of much help with the cloud sync angle, but
             | for CryFS and GocryptFS support in Droid, you might find
             | DroidFS worth a look.
        
         | didntcheck wrote:
         | I've not used it myself, but there's also CryFS [1]. It's file-
         | level like EncFS or eCryptFS, but uses fixed-size and padded
         | cypherfiles to avoid leaking details about your file structure.
         | I'm not sure about Cryptomator, but with EncFS it would be
         | relatively easy to infer that someone has, say, the Tor browser
         | stored in it, by the size and shape of the encrypted files
         | 
         | [1] https://www.cryfs.org/
        
           | riedel wrote:
           | Cool, I did not know it, and is a product from a master
           | thesis at our university. Have to try it.
           | 
           | People complain about speed in the past :
           | https://news.ycombinator.com/item?id=23469401
           | 
           | Is it usable?
        
           | 8fingerlouie wrote:
           | CryFS (and gocryptfs) both suffer from the same lack of
           | support on iOS, which Cryptomator has, which is the reason
           | i'm sticking with it.
           | 
           | As for how it encrypts files, there is a description here : h
           | ttps://docs.cryptomator.org/en/1.5/security/architecture/#f..
           | .
        
           | alwyn wrote:
           | I'm a fan of gocryptfs [1]/cppcryptfs (Windows
           | implementation) [2], they also have a fairly unbiased
           | comparison [3] with other solutions, including CryFS.
           | 
           | [1] https://nuetzlich.net/gocryptfs/
           | 
           | [2] https://github.com/bailey27/cppcryptfs
           | 
           | [3] https://nuetzlich.net/gocryptfs/comparison/
        
       | stblack wrote:
       | I always wonder what really happened with TrueCrypt. What's the
       | inside story, there?
       | 
       | I'm not interested in anybody's guess. What happened? WTF
       | actually happened?
        
         | etc-hosts wrote:
         | Paul Leroux was sentenced to 25 years in June 2020, appellate
         | court confirmed the sentence in 2022.
         | 
         | https://law.justia.com/cases/federal/appellate-courts/ca2/20...
        
           | icelancer wrote:
           | Didn't he consistently deny being involved in TrueCrypt? E4M
           | is closely related, but is there any evidence showing that
           | Paul == TrueCrypt? Just curious if there was.
        
             | stef25 wrote:
             | There's no proof
        
           | pyuser583 wrote:
           | > The district court's decision that immediate video
           | sentencing was in defendant's best interest was reasonable
           | because defendant was asking for a time-served sentence ...
           | 
           | Time served was 25 years!?!
        
             | etc-hosts wrote:
             | Leroux has been in custody since 2012. If he was sentenced
             | to 25 years in 2020... he would only have 17 years to
             | serve. it's 2023 now, so he has 14 years left.
        
           | jandrese wrote:
           | That is wild. How did he have time to maintain TrueCrypt
           | while doing all of that crime?
        
             | runjake wrote:
             | Paul was what people call a 10x programmer. He was highly
             | prolific.
             | 
             | The book Mastermind goes into this a bit.
             | 
             | So do some old web posts straight from Paul himself, if you
             | know where and if they are still up.
        
               | rjzzleep wrote:
               | Has anyone looked up the details of all of this? The DEA
               | has been notorious for arresting people overseas and
               | indicting them for just participating(i.e. being in the
               | same room) in conversations about drug trafficking even
               | if those conversations were between DEA agents.
               | 
               | Just a quick glimpse at the Wikipedia page actually talks
               | about 5 drugs that seem to me like over the counter
               | medicine. What's kinda interesting to me skimming this
               | and looking at the references is that the assassins and a
               | lot of the operations were Israelis and the whole thing
               | was run from Tel Aviv, but there's zero reference to any
               | of those people. They are just called the Israeli
               | business partners.
        
               | runjake wrote:
               | I'm on mobile but there's more info on the Israelis in
               | the Mastermind book. Some of them still have public
               | LinkedIn profiles.
        
               | oldnet wrote:
               | I noticed that US fed agencies work like that - use
               | someone for their own games and make it looks like
               | success job for own careers.
               | 
               | Some cops tried it in my country as well. These cops
               | recieved a middle finger from the court.
               | 
               | Edit: The courts called it 'provocation by police' and
               | everyone was freed.
        
           | hosteur wrote:
           | He denies involvement with TrueCrypt. Is there any actual
           | proof?
        
           | e12e wrote:
           | Oh I'd forgotten about this part:
           | 
           | > Le Roux was arrested on 26 September 2012 for conspiracy to
           | import narcotics into the United States, and agreed to
           | cooperate with authorities in exchange for a lesser sentence
           | and immunity to any crimes he might admit to later. He
           | subsequently admitted to arranging or participating in seven
           | murders, carried out as part of an extensive illegal business
           | empire.
           | 
           | https://en.m.wikipedia.org/wiki/Paul_Le_Roux
        
         | perth wrote:
         | I've always heard speculation that I believe of some sort of
         | NSA involvement. When it was taken down back in the day (yes it
         | was pretty much a takedown, the entire website got thrashed..)
         | there was a lot of people on Reddit that were speculating that.
        
           | didntcheck wrote:
           | The way it was announced was suspicious. Purging the website
           | rather than just posting an "unmaintained" notice is weird
           | for any FOSS project, but recommending people just use
           | Bitlocker sounded like a clear "canary". Like the authors
           | were being coerced and decided to burn their reputation on
           | purpose rather than comply
        
           | goalieca wrote:
           | The "Not Secure Anymore" message likely refers to the weak
           | password based key derivation function and verification
           | steps. I suspect the NSA and other advanced computing groups
           | had means to brute force it and it took the rest of us years
           | to figure out the parameters weren't strong enough.
        
         | lucb1e wrote:
         | I'm not sure how you're insisting on more than "anybody's
         | guess" when that's all the information that is out there
        
         | eitland wrote:
         | For anyone who wonders and can tolerate some guessing, here is
         | an interesting starting point:
         | 
         | https://magazine.atavist.com/he-always-had-a-dark-side/
        
           | billfruit wrote:
           | The the article may have something interesting to say, but it
           | seems to spend paragraphs upon paragraphs on the amateur
           | sleuthing that the article authour did, rather than come to
           | the point quickly.
        
             | eitland wrote:
             | In other words what many of us would call an interesting
             | article :-)
        
           | wkat4242 wrote:
           | I had no idea, that explains a lot. Thanks.
        
           | ThePowerOfFuet wrote:
           | Absolutely wild. Thank you for contributing this!
        
       | goombacloud wrote:
       | For regular Linux users you can do:                 sudo touch
       | /etc/udisks2/tcrypt.conf       sudo systemctl restart udisks2
       | 
       | and then any veracrypt volumes can be used in Nautilus or GNOME
       | Disks similar to LUKS volumes.
        
         | [deleted]
        
       | LWIRVoltage wrote:
       | I have followed Veracrypt closely over the years and , while it
       | works very well and seems to be a very capable effective option-
       | I wish the MBR/BIOS vs UEFI thing wasn't a limitation
       | 
       | For those who don't know, -and this is more of the result of the
       | EFI Boot partition scheme- before that, for MBR systems ,one can
       | use Veracrypt to encrypt the entire System Drive - and this
       | allowed a unique option that I have not seen anything else ever
       | able to replicate- it enables an option that lets one hide an
       | entire OS-
       | 
       | The Hidden OS option is restricted to legacy boot mode- and
       | that's being more and more dissuaded in general- So i fear the
       | airtightness of the Hidden-OS capability will no longer be
       | reachable for consumers.
       | 
       | I had seen one effort on it - https://portswigger.net/daily-
       | swig/russian-doll-steganograph...
       | 
       | and https://i.blackhat.com/eu-18/Thu-Dec-6/eu-18-Schaub-
       | Perfectl...
       | 
       | However, I have since then not seen anything on this sort of
       | capability- and no other encryption software has focused on
       | steganography and encryption/plausible deniability capabilities
       | to this level.
        
         | somat wrote:
         | It should be a common thing, I am not all that sure about the
         | offerings on linux. But the openbsd project offers full disk
         | encryption and a bootloader that handles it well.
         | 
         | Actually, this may be a common mistake I make. On openbsd if
         | the project says something works it will usually be simple to
         | set up and have a nice documentation. So I then think "Well if
         | the tiny openbsd project can do it, it must be this easy
         | everywhere" which is not true at all. The two cases that come
         | to mind were booting off a softraid volume(hopefully this one
         | is fixed) and setting up a netflow source. both of which proved
         | to be trivial on openbsd and a huge pain in the ass on linux.
         | The other common mistake I make is to use the openbsd man
         | pages(they are just better) on linux and wonder why nothing is
         | working right.
        
       | NetworkPerson wrote:
       | I love it, but it's not an answer to normal people yet. The 0.01%
       | of us who know and understand encryption, cool. But getting ready
       | for the main world? Bitlocker lets people click a button and walk
       | away. Administrators make a few small changes and have the whole
       | fleet bitlockered with centrally managed recovery keys should
       | anyone have an issue. Does Veracrypt offer better security? Yes.
       | Would I be thrilled to roll it to my clients? Yes. Would it be an
       | absolute nightmare to deploy and manage across an organization?
       | Yes.
       | 
       | I'm sad because this is great and the answer to much but stands
       | no chance when you move past the "single user who is IT literate"
       | user group.
        
         | Groxx wrote:
         | Bitlocker for an equivalent level of security (password at
         | boot) is _way_ more confusing and _way_ more error prone in my
         | experience. I know what I 'm looking for and understand all the
         | terms in use and I had to try three times, and lost access to
         | my drive once.
         | 
         | No way in hell would I recommend it to less technical people
         | (except default settings, which works fine but offers near zero
         | security against extremely common things like theft). Bitlocker
         | is by far the least user-friendly OS-provided I've ever seen -
         | it's so bad I have to assume it's being intentionally ruined.
        
         | upon_drumhead wrote:
         | Is it better? Even truecrypt's developers (which this is based
         | on) recommend moving to bit locker now,
         | https://truecrypt.sourceforge.net
        
           | kijin wrote:
           | That was 9 years ago, not "now". BitLocker was the only
           | alternative that they could recommend back then.
           | 
           | It's possible that whatever vulnerability the TrueCrypt
           | developers were alluding to still lurks in the VeraCrypt
           | codebase, but the chances seem pretty low. VeraCrypt uses
           | much stronger encryption methods, it has addressed all the
           | issues raised in the original TrueCrypt audit as well as a
           | separate audit of its own code, and the latest version isn't
           | even backward-compatible with TrueCrypt volumes.
        
             | cypress66 wrote:
             | No, recommending bitlocker back then was basically a joke
             | to anyone at that time, an obvious way of telling you
             | something wrong.
             | 
             | The obvious recommendation back then was LUKS. And even if
             | there were no alternatives they're not going to recommend
             | you a proprietary solution with a high chance of being
             | backdoored. They'll just say to use "other software".
        
               | kijin wrote:
               | The majority of TrueCrypt users were on Windows and
               | needed a GUI. Backdoors or not, BitLocker was the only
               | comparable alternative.
               | 
               | Recommending BitLocker might have been a signal to
               | hackers in the aftermath of the Snowden revelations, but
               | IIRC the announcement also included a detailed tutorial
               | for setting up BitLocker that was actually quite helpful
               | to anyone whose threat model mostly concrerned thieves,
               | corporate spies, and non-Five Eyes intelligence agencies.
        
             | 13415 wrote:
             | This probably has nothing to do with vulnerabilities in the
             | source code, it has to do with the observations that Mounir
             | Idrassi took over truecrypt very fast when it was shut
             | down, yet was not known in cryptography circles prior to
             | this at all, and his company idrix.fr looks _a lot_ like a
             | typical DGSE shell company. It is unclear what kind of
             | contracts it had (if any) before it dedicated seemingly
             | most of its time to Veracrypt.
             | 
             | Of course, it would be the binaries that are problem, if
             | there is one. If you vet the source code and compile it
             | yourself, there shouldn't be any issue. Note that the
             | French government has long history of being anti-
             | cryptography for end-consumers.
             | 
             | I personally wouldn't even touch Veracrypt with a long
             | pole. But that's just my personal opinion.
        
               | paulryanrogers wrote:
               | Do you believe the audit was compromised as well?
               | 
               | https://ostif.org/the-veracrypt-audit-results/
        
             | rkagerer wrote:
             | _the latest version isn 't even backward-compatible with
             | TrueCrypt volumes_
             | 
             | Are you sure? I thought it could open them in read-only
             | mode. Here's a 2023 post suggesting it's supposed to still
             | be able to open TC 6.0+ files, though the user in question
             | is having trouble: https://sourceforge.net/p/veracrypt/disc
             | ussion/technical/thr...
        
           | two_in_one wrote:
           | LOL, that was when they _removed_ all encryption in their
           | last, final update. That was part of the deal probably, but
           | they made it so obvious that nobody took it seriously.
           | Everybody got the message: something is going wrong.
           | 
           | Since then truecrypt was carefully reviewed, some bugs were
           | found, but no backdoors. It was forked and veracrypt is one
           | of those forks. It has enhanced security which makes it
           | annoying to use. For example to disconnect the drive one
           | needs to enter admin's password. That's done because
           | veracrypt doesn't store it. On one hand it makes it more
           | secure, on the other entering passwords many times in public
           | makes it less.
        
             | sangnoir wrote:
             | > LOL, that was when they _removed_ all encryption in their
             | last, final update
             | 
             | That's was the time the other Truecrypt contributors
             | learned that Paul le Roux was in federal custody[1]. Most
             | likely they nukes encryption & gave dire warnings as a
             | scorched earth play to avoid the possibility of an FBI-
             | authored binary release of TrueCrypt, since Paul controlled
             | the website and the infrastructure, IIRC.
             | 
             | 1. Warning: linked story is a 3-part longform story that
             | can cause 30-60m to vanish from your day.
             | https://magazine.atavist.com/he-always-had-a-dark-side/
        
             | LoganDark wrote:
             | > For example to disconnect the drive one needs to enter
             | admin's password. That's done because veracrypt doesn't
             | store it.
             | 
             | What? For me, VeraCrypt can mount and unmount volumes (on
             | Windows 11) without ever prompting for UAC. It could also
             | do the same on my other, Windows 10 PC.
        
               | two_in_one wrote:
               | On Ubuntu it requires admin pas on every action. Like
               | mount/unmount. On truecrypt it's on click. Sadly they are
               | not compatible. Not sure, did veracrypt pass external
               | audit like truecrypt?
        
         | BeetleB wrote:
         | Veracrypt is a fork of TrueCrypt, which _was_ used by lots of
         | low tech people (I know some personally). For certain use
         | cases, it 's pretty straightforward to use. I suspect that at
         | that time, it was the simplest highly secure SW that was
         | available to people: Free and open source.
         | 
         | Comparing with Bitlocker is silly - its source is closed, and
         | that's almost an automatic "untrustworthy" for many. It also is
         | Windows only.
        
           | kinleyd wrote:
           | Veracrypt works on Linux too. I switched over when Truecrypt
           | was orphaned.
        
             | genezeta wrote:
             | I'd say they meant _Bitlocker_ is Windows only.
        
               | kinleyd wrote:
               | Ah, you're right. I realized that was probably what was
               | meant after I'd posted.
               | 
               | I never realized there was so much history - just thought
               | the app had been orphaned for the usual mundane reasons.
               | I've got to read that book!
        
           | jolux wrote:
           | > that's almost an automatic "untrustworthy" for many
           | 
           | "Many" is probably overstating things relative to the full
           | audience for Bitlocker
        
           | [deleted]
        
         | Shorel wrote:
         | I don't think the target of Veracrypt is to be used by
         | corporations.
         | 
         | Almost by definition, corporations will sell their souls to MS
         | if that means "accountability", that means someone to blame
         | when things go wrong. Not if, when.
         | 
         | Just the fact Veracrypt exists and can be used by that 0.01% is
         | enough. It is already useful beyond expectations.
        
       | ciabattabread wrote:
       | I use VeraCrypt on Windows to store my bank statements and other
       | financial records, but recently, I've started moving my files
       | over to the Mac ecosystem. Considering my Mac comes with SSD
       | encryption, is it really necessary for me to continue using
       | VeraCrypt?
        
         | SamuelAdams wrote:
         | Probably not. What is your threat model? Full disk encryption
         | only solves part of an overall threat model. The biggest
         | difference between VeraCrypt and FileVault is that one is open
         | source and auditable. FileVault does have some publicly
         | available technical whitepapers, however Apple has not released
         | the source code. So aside from black box testing FileVault
         | itself, you'll just have to trust that the engineers at Apple
         | did a good job. Otherwise the differences are largely the same:
         | how long is your passphrase, where do you store that, etc.
         | https://www.lightbluetouchpaper.org/2012/08/06/analysis-of-f...
         | https://eprint.iacr.org/2012/374.pdf
        
       | yomlica8 wrote:
       | I was sort of surprised to find that standard crypt-setup in
       | linux actually supports opening true/veracrypt volumes. It
       | doesn't support creating them as near as I can tell though.
        
       | urbandw311er wrote:
       | The reason I knew Trucrypt was watertight was because the source
       | code got fully audited and because the NSA got so squirmy about
       | it.
       | 
       | Has there been any equivalent audit of Veracrypt? Or should we
       | basically assume it's been compromised/backdoored.
        
         | I_Byte wrote:
         | Veracrypt 1.18 was audited in 2016 by the Open Source
         | Technology Improvement Fund [0]. It is incredibly unlikely that
         | a random NSA backdoor is sitting around on a high profile open
         | source project like Veracrypt. If you are still skeptical you
         | are free to take a look at all of the source yourself [1].
         | 
         | [0] - https://ostif.org/the-veracrypt-audit-results/
         | 
         | [1] - https://github.com/veracrypt/VeraCrypt
        
       | jillesvangurp wrote:
       | Development seems to have moved to Github. This website has the
       | latest release in 2022. The Github project has much newer
       | releases: https://github.com/veracrypt/VeraCrypt/releases. Today
       | basically.
        
         | deanc wrote:
         | On the downloads page [1] the latest release is in sync with
         | Github
         | 
         | [1] https://veracrypt.fr/en/Downloads.html
        
       | vishnudeva wrote:
       | Amazing tool, but I'll always (unreasonably and unfairly) hate it
       | for locking away a bunch of my data because I forgot an absurdly
       | long password which I didn't note down anywhere. Needless to say,
       | lesson learned.
        
         | ycuser2 wrote:
         | I have an old WinRAR archive which password I have forgotten.
         | Who knows, maybe in 50 years we will be able to read the
         | encrypted stuff.
        
         | ct0 wrote:
         | tough lesson, but i hope you use a password manager now.
        
       | pollux66 wrote:
       | [flagged]
        
       | T3RMINATED wrote:
       | [dead]
        
       | Ayesh wrote:
       | Using it for a few years now, and I'd hesitate not one bit to
       | recommend. It's not as "technical" as said in comments either
       | tbh. But us in HN are not qualified to call it non tech friendly
       | I guess.
       | 
       | Performance is great, nearly "metal" SSD speeds. I use it with a
       | hidden partition of an external HDD, and works great too, once I
       | got Windows to stop asking me to formally that partition.
       | 
       | The only feature I wish it could have is better Yubikey (and
       | alike) integration. I can use those static passwords as an
       | encryption key, but I'd need something better.
        
         | _d3Xt3r_ wrote:
         | > Performance is great, nearly "metal" SSD speeds.
         | 
         | But how does that compare exactly, performance wise, against
         | Bitlocker and LUKS? (assuming similar strength encryption
         | algorithms are selected)
        
           | baxuz wrote:
           | Bitlocker is Microsoft's closed-source product. How can you
           | be sure it doesn't have backdoors?
        
             | shim__ wrote:
             | That question is pointless if you're using windows
        
               | huhtenberg wrote:
               | In practice, it is most certainly not pointless.
               | 
               | Given two USB drives, one encrypted with BitLocker and
               | another with TC or VC, chances of master key recovery by
               | Microsoft are definitely not the same.
        
               | maccard wrote:
               | > In practice, it is most certainly not pointless ....
               | chances of master key recovery by Microsoft are
               | definitely not the same.
               | 
               | I don't think those two sentences hold water when put
               | together. _In practice_ , if your risk is master key
               | leakage and theft of the encrypted data by microsoft, you
               | shouldn't be using windows. If you suspect that, MS can
               | have a kernel mode driver masquerading as anything else,
               | and it can just siphon your master key whenever you enter
               | it.
        
               | DarkmSparks wrote:
               | And now that ms auth is apparently mostly compromised,
               | extend microsoft to any threat actor in the wild.
               | 
               | I like VC for the portability of the encrypted .tc files.
               | Keep all my backups as tc files, and recovered from more
               | than one failure using them.
               | 
               | Once had an issue where dropbox corrupted the duplicates,
               | so dont use dropbox anymore.
        
               | Jerrrry wrote:
               | >ms auth is apparently mostly compromised
               | 
               | just gonna drop that like that aint a $10k+ implication,
               | gonna need a src or ref thanks
               | 
               | unless you mean by 3letters, which dont exactly give
               | their backdoors to randoms.
               | 
               | randoms aint coming across 3letter's backdoors, not
               | active/modern ones anyway
        
               | lapinot wrote:
               | https://news.ycombinator.com/item?id=37702095
               | 
               | it's probably more than a $10k implication..
        
           | Ayesh wrote:
           | I haven't used BitLocker or anything else, so I can't really
           | compare.
           | 
           | Veracrypt has a neat benchmark tool so you know the speed
           | beforehand. I suppose most CPUs have native support for the
           | popular algorithms, so the bottleneck really is the disk, not
           | CPU itself or the software.
        
           | pulse7 wrote:
           | There is still an open issue in VeraCrypt
           | (https://github.com/veracrypt/VeraCrypt/issues/136) because
           | of which BitLocker is much faster on SSDs then VeraCrypt...
           | But if you don't need those speads, VeraCrypt is still
           | great...
        
             | huhtenberg wrote:
             | To nitpick - on _NVmE_ drives, not SSDs.
             | 
             | The principal difference is the native speed of raw IO -
             | NVmEs are an order of magnitude faster than SSDs. TC/VC
             | don't use hardware acceleration, so all the encryption work
             | falls on the CPU. On a machine with a reasonably modern
             | CPU, TC/VC run nearly at drive's native speed.
        
               | seanw444 wrote:
               | > TC/VC don't use hardware acceleration
               | 
               | I assume by that you mean it doesn't use the AES
               | instructions? That's odd to me.
        
               | fluoridation wrote:
               | No, that's wrong. VeraCrypt uses AES-NI when available.
               | It seems the source of the issue is the IO design of the
               | driver, which causes unnecessary context switches when
               | operating on a raw device.
        
               | seanw444 wrote:
               | Okay that makes more sense.
        
           | [deleted]
        
         | aeyes wrote:
         | > I can use those static passwords as an encryption key, but
         | I'd need something better.
         | 
         | I use static password plus a keyfile. Since the keyfile can be
         | anything you can use something innocent looking which you just
         | have laying around on the machine, like a picture.
        
           | sangnoir wrote:
           | > you can use something innocent looking which you just have
           | laying around on the machine, like a picture.
           | 
           | This works well on a file you decrypt often. What can happen
           | with infrequently used files is that many years pass, you
           | upgrade computers and/or operating systems, remember to copy
           | your encrypted volumes. When you try to decrypt your volume,
           | you remember the passcode, but forget which "innocuous" file
           | you used as a keyfile, even after you boot up your old
           | computer you had handed down to your cousin.
        
             | aeyes wrote:
             | Well, the same happens to me with passwords which I don't
             | use for a long time.
             | 
             | You can use any file, even something you can quickly
             | download from the Internet. Like the Windows 3.11 file
             | manager icon or your favorite Linux torrent. Only the first
             | 1024 bytes are used so be careful with file types which
             | have a big header.
        
           | somat wrote:
           | If you can make a key file You can put it on a removable sd
           | card and make a keydrive. This introduces a nice air gap to
           | the key, only needing to be broken when unlocking the drive.
           | 
           | There are better ways, often the the key can be stored on a
           | hardware token(yubi key etc... ). which presumably offers
           | additional security guarantees around copying the key. but a
           | keydrive is a very easy way to start.
           | 
           | Off tangent(I doubt you will be using openbsd), but the
           | openbsd encryption layer offers some nice features around
           | using keydrives,
           | http://www.openbsd.org/faq/faq14.html#softraidFDE
        
         | Reviving1514 wrote:
         | I've seen reports of corrupted files and that has always
         | stopped me from using it. I even paid for the Android app just
         | to support them.
         | 
         | Is file corruption still an issue?
        
           | kristofferg wrote:
           | Ime. not more than any other encryption tool. Just don't skip
           | or delay those backups.
        
           | Ayesh wrote:
           | > still
           | 
           | Never had problems. FWIW, I'm using AES/256 bit keys/HMAC
           | SHA-512 on all of my volumes.
        
         | RockRobotRock wrote:
         | Functionally, how could anything be better than a static
         | password?
        
           | Ayesh wrote:
           | I meant the long static passwords Yubikeys "type" when you
           | touch the button when plugged in. It's just a static long
           | text that has no context.
        
             | RockRobotRock wrote:
             | Sorry, I know what you mean. I'm saying anything like
             | challenge-response would still be a password functionally
             | if you're decrypting a static file.
        
           | wannacboatmovie wrote:
           | BitLocker and LUKS both support TPM for key storage which
           | VeraCrypt does not.
           | 
           | The TPM acts as a second factor (assume PIN is required); if
           | you pulled the disk out and placed it another PC you cannot
           | brute force the plaintext password, even using the $5 wrench
           | method.
        
             | hexfish wrote:
             | I would be very careful with placing my trust in TPM:
             | https://www.secura.com/blog/tpm-sniffing-attacks-against-
             | non....
        
               | KAMSPioneer wrote:
               | Your parent comment said he was assuming a PIN was used
               | to seal the TPM, and the attacking the link would have
               | failed if the TPM had a PIN set, no? I agree though that
               | using a TPM without a PIN gives little in the way of data
               | protection. Not nothing, but little.
        
               | nuker wrote:
               | Sniffing the bus can be defeated by using encrypted
               | comms. It is disabled by Windows for some reason, but it
               | works as designed in other secure boot implementations. I
               | hope :)
        
             | EVa5I7bHFq9mnYK wrote:
             | does that mean if morherboard goes kaput, so does all my
             | data? I have 7 layers of backup, but still interesting to
             | know.
        
               | wannacboatmovie wrote:
               | No, it typically generates a recovery key which you can
               | keep offline (or discard and live dangerously).
        
             | pmontra wrote:
             | > even using the $5 wrench method
             | 
             | I understand the XKCD reference but I don't understand why
             | it does not apply to this case. Does that mean that you
             | can't move your disk to a new machine of yours?
        
               | alias_neo wrote:
               | Because if you took the disk, even if you $5-wrenched the
               | pin out of someone, you don't have the TPM hardware to
               | make use of it.
               | 
               | As for the second question, I suppose it depends on the
               | implementation; I suspect there is a way to migrate and
               | transfer the keys for the device for the person who
               | already has access to all of the factors.
               | 
               | If I use a Yubikey and LUKS for example, I can re-use the
               | Yubikey if I move the disk to another machine. I'm not
               | sure how this would work for integrated TPMs and
               | Bitlocker (I don't use Windows), but I believe they have
               | recovery key-files you could use.
        
               | forty wrote:
               | > Because if you took the disk, even if you $5-wrenched
               | the pin out of someone, you don't have the TPM hardware
               | to make use of it.
               | 
               | I sincerely hope that the guy with the $5 wrench knows
               | this and don't continue hitting until he has the key...
        
               | mkopec wrote:
               | Indeed, it seems that having another unlock option might
               | be preferable. If you value your own live over the
               | secrets, that is.
        
               | pmontra wrote:
               | If there is no way to transfer the disk to another
               | machine, it's not a disk I want to use. I think that
               | there are very few use cases for losing all the data when
               | a machine dies.
               | 
               | And if there is a procedure to let me move the disk to a
               | new machine, somebody can wrench me until I perform that
               | procedure for them.
        
               | mkopec wrote:
               | With LUKS you can enroll an extra auth option in addition
               | to TPM, like a password or a FIDO2 token.
        
               | alias_neo wrote:
               | > And if there is a procedure to let me move the disk to
               | a new machine, somebody can wrench me until I perform
               | that procedure for them.
               | 
               | I think the implication is that they (the attacker) don't
               | have the machine, or you, or whatever "thing" you
               | have/use to unlock it.
               | 
               | If someone stole your disk, or took a copy of it, they
               | can't offline attack it.
               | 
               | An external hardware device seems preferable for this
               | scenario; if someone steals/snatches your laptop, they
               | won't have your Yubikey or whatever.
               | 
               | In any scenario where the wrenching is an option, I
               | suspect all bets are off, but if wrenching is a real
               | risk, and whatever you're protecting is worth taking a
               | wrenching for (as opposed to just giving it up at the
               | threat of a wrenching), there should probably be some
               | tougher protections which make it clear that the
               | wrenching will gain an attacker nothing, and hopefully
               | save you from it to begin with.
               | 
               | I'm not sure what or how that would work.
        
               | dwattttt wrote:
               | For Bitlocker (and I imagine other tools which support
               | TPM keying), a recovery password is generated in addition
               | to the TPM unlock key. If the motherboard goes kaput you
               | dig out the long key to unlock it, assuming you kept it
               | somewhere safe (speaking as someone who has had to dig
               | through a pile of old USBs to get access back to a disk).
        
               | robertlagrant wrote:
               | Sounds as though this is where the $5 wrench would work
               | just fine.
        
               | mkopec wrote:
               | It's a matter of priorities, I guess?
               | 
               | If you want to you can just not save the recovery
               | password. In that case I guess they'll just beat you to
               | death with that $5 wrench.
        
       | maattdd wrote:
       | VeraCrypt is good but it doesn't work well with syncing, because
       | changing any bit of the disk image invalidate the whole disk
       | hash. Cryptomator works a bit differently (it changes the
       | structure/names, but store the underlying encrypted files as
       | files) so you can sync file by file.
        
         | aborsy wrote:
         | Veracrypt is a disk encryption tool, not for syncing!
        
           | maattdd wrote:
           | I don't think you've understood my comment.
        
             | aborsy wrote:
             | I have done this and been there before.
             | 
             | Dropbox syncs the deltas in LUKS and veracrypt disks. A
             | change of a bit in plaintext changes the blocks that are
             | involved, and only those blocks are updated. But most other
             | sync tools don't handle it properly.
             | 
             | That was around a decade ago. Today, one would use
             | cryptomator, rclone, gocryptfs rtc.
        
         | MikusR wrote:
         | And propper syncing tools can sync only the changed parts.
        
           | maattdd wrote:
           | Do you know a syncing tool which would work with a VeraCrypt
           | image? (rsync algo doesn't for example)
        
             | Groxx wrote:
             | Rsync syncs only differing blocks of data (not whole files)
             | by default - it's pretty much the reason it is so popular.
             | 
             | There are a lot of ways to lose that though. No rsync able
             | to run and calculate block checksums on the other machine
             | -> no block syncing. Change a byte in a file in an
             | encrypted volume -> it might copy-on-write and make a
             | wholly new encrypted "file" with everything different in
             | the final encrypted data. Etc, it depends on a bunch of
             | stuff interacting in ways that they might have legitimate
             | reasons to not support, particularly with security/privacy
             | sensitive stuff.
             | 
             | Not sure what you're encountering, but if it's important to
             | you there are a few ways to troubleshoot it. It might be
             | possible to get it working.
        
             | aeyes wrote:
             | Works fine with rsync here.
        
         | apankrat wrote:
         | This can be remedied by using tools that can do block-wise
         | (delta) copying of large files, e.g.
         | https://bvckup2.com/kb/delta-copying
        
         | ale42 wrote:
         | I think that VeraCrypt and Cryptomator have very different use
         | cases. And VeraCrypt has features like hidden volumes (not that
         | most people would ever need those).
        
       | nuker wrote:
       | Can it set-up /boot volume encryption and using of TPM for
       | unattended reboots? Thats the deal breaker feature.
        
         | iofiiiiiiiii wrote:
         | I once asked the developers about this and they did not seem to
         | understand what the point of a TPM even is, unfortunately.
        
       ___________________________________________________________________
       (page generated 2023-10-02 23:02 UTC)