VeraCrypt: Free open-source disk encryption for Windows, Mac OS X, Linux | Hacker News Reader

VeraCrypt: Free open-source disk encryption for Windows, Mac OS X, Linux

veracrypt.fr

384 pointsthunderbong198 comments

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

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.

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?

I use syncthing for this. But yeah it isnt ideal.

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.

Yep unfortunately the same still applies with DroidFS. Thanks though.

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/

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/

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 : https://docs.cryptomator.org/en/1.5/security/architecture/#f...

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?

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/

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.

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

Round-Sync for Android [0] is an app wrapper for rclone. I use that to upload my photos via plain SSH.

[0] https://github.com/newhinton/Round-Sync

Rclone doesn't work too well on mobile though, which is where cryptomator is really nice.

RCX on android[0] gives a reasonable experience for pecking at files (Also handles media streaming reasonably well and supports the Crypt remote mentioned in the parent)

[0] https://github.com/x0b/rcx

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.

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

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.

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.

I use CryFS combined with SyncThing, perfect solution for my needs. Have it set up on linux and android.

I tried many, many sync solutions (I self host a lot) but syncthing always looked weird to me.

One day I forced myself to actually configure it and, boy, what a wonderful product it is.

It takes some time before you have the eureka moment but then the flexibility of the tool us incredible.

It is hard to keep track of the links so I wrote https://github.com/wsw70/syncthing-map to ease the pain a little bit.

Does Cryptomator also works over sftp? Does it supports concurrent edits to the same vault? Can't find much about it in the docs...

Yep I use Cryptomator for when I want to sync a bunch of small individual files, and Veracrypt for big local archives. I forget whether I have cryptomator hooked up to Dropbox or google drive, but I’ve never had an issue with it.

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/

>tangential

thanks for this, it was useful to me though i reflexively typed up a comment asking you be careful about truecrypt vs veracrypt as i tried to load your article[1] via tor browser.

(through no fault of your own, i am having flashbacks to documents referencing "ethereal" and "firebird" far too long -- when the wrong word is used past the change in name, many will use that as a heursistic to discount your words and data, sometimes it's cruel to those who learned english late in life but it's the only way to avoid some very dangerous errors, especially if you are moving from "the cyber" to the physical in terms of the sources you're... pulling)

(i can assure you that most stenography is best reserved for key exchange, not hiding any significant amount of data, but most users of this site are concerned with a very US-centric, legalistic threat model where no lies are told to totalitarians.)

[1] https://web.archive.org/web/20110916033048/https://keyj.emph...

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.

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

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.

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

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.

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

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.

Okay that makes more sense.

You can also explicitly disable the AES-NI in Veracrypt and use pure software implementation if you don't trust the hardware. I usually enable this option.

This option always seems funny to me. If I didn't trust the AES-NI instruction, why I would I trust the XOR instruction?

You could probably imagine the possibility of state actors and Intel, for example, conspiring to backdoor AES instructions of specific targets. Maybe possible with the IME. Not accusing them of this, but it's not out of the realm of possibility. The only things using the AES instructions are important data needing to be encrypted.

On the other hand, trying to backdoor XOR would give you an astronomically higher amount of white noise. Finding important data mixed in with all the other things a computer XORs would be much harder.

The CPU would "just" need to look at all executable pages to find binaries of common AES implementations, and when it finds one it could wait for the key to be loaded and then exfiltrate it. It could also detect (although at greater effort, possibly much greater) when you're using it to compile AES and inject spying code into the output, even if the target is a different architecture.

If the attacker has access to your computer, you've already lost. If the attacker built your computer, it was never even a fight.

Bitlocker is Microsoft's closed-source product. How can you be sure it doesn't have backdoors?

That question is pointless if you're using windows

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.

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

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.

>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

https://news.ycombinator.com/item?id=37702095

it's probably more than a $10k implication..

Functionally, how could anything be better than a static password?

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.

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.

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.

I would be very careful with placing my trust in TPM: https://www.secura.com/blog/tpm-sniffing-attacks-against-non....

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.

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 :)

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

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.

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.

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).

Sounds as though this is where the $5 wrench would work just fine.

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.

That's why I'd rather use a service without a recovery password :)

With LUKS you can enroll an extra auth option in addition to TPM, like a password or a FIDO2 token.

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

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

Indeed, it seems that having another unlock option might be preferable. If you value your own live over the secrets, that is.

does that mean if morherboard goes kaput, so does all my data? I have 7 layers of backup, but still interesting to know.

No, it typically generates a recovery key which you can keep offline (or discard and live dangerously).

ok, so the $5 wrench method can be used to extract the recovery key.

You typically print it and store it in a safe place (like your home cabinet). It's something like 256bit random number, no way to recall it, especially while being subjected to the $5 wrench method.

No need to recall 256 bits, just which cabinet.

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?

Ime. not more than any other encryption tool. Just don’t skip or delay those backups.

> still

Never had problems. FWIW, I'm using AES/256 bit keys/HMAC SHA-512 on all of my volumes.

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

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

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.

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

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?

I'm not sure how you're insisting on more than "anybody's guess" when that's all the information that is out there

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/

I had no idea, that explains a lot. Thanks.

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.

In other words what many of us would call an interesting article :-)

The article writer focusing on themselves rather than on their subject makes it less interesting for me.

Absolutely wild. Thank you for contributing this!

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

That is wild. How did he have time to maintain TrueCrypt while doing all of that crime?

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.

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.

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.

I’m on mobile but there’s more info on the Israelis in the Mastermind book. Some of them still have public LinkedIn profiles.

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.

There's no proof

> 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!?!

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.

He denies involvement with TrueCrypt. Is there any actual proof?

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

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.

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

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.

The alternate theory was that the NSA forced the project to shutdown or become backdoored because they couldn't break it, and that was deemed unacceptable, resulting in the author deciding to call it quits (lavabit style) rather than compromise the application. The question then becomes "why is VeraCrypt allowed to exist"

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.

Is it better? Even truecrypt's developers (which this is based on) recommend moving to bit locker now, https://truecrypt.sourceforge.net

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.

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".

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.

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.

Do you believe the audit was compromised as well?

https://ostif.org/the-veracrypt-audit-results/

They audited the source code. I was talking about the executables on their website. Intelligence agencies tend to substitute binaries with compromised executables when they are downloaded by specific targets. We know that's what the NSA was routinely doing (among other things like hardware interception) from the Snowden revelations. There is no reason to believe DGSE works differently. Of course, it is also possible to provide compromised source code to specific targets if necessary.

Replacing binaries for specific targets certainly happens more than one would like. This has even happened specifically with TC and VC files in the past. A mitigating circumstance though with Veracrypt is that the binaries also have detached GPG signatures that one can check against IDRIX's public key to verify that it is in fact what Idrassi has released on the website. It's still possible for actors to tamper with the binaries in other ways even if signed, so it's best to pull from source and periodically check the diffs.

If you read my original post again, unfortunately my lack of trust is exactly with Idrassi and IDRIX. Other than that, I agree.

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/discussion/technical/thr...

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.

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

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?

> Not sure, did veracrypt pass external audit like truecrypt?

I believe they incorporated the recommendations from TrueCrypt's own audit, and then went through an additional external audit that came up clean.

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

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.

> that's almost an automatic "untrustworthy" for many

“Many” is probably overstating things relative to the full audience for Bitlocker

Veracrypt works on Linux too. I switched over when Truecrypt was orphaned.

I'd say they meant Bitlocker is Windows only.

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!

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.

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.

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

Not trying to diminish zulucrypt here but I really hope people aren't choosing encryption programs based on the GUI framework they use.

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.

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.

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.

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

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.

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.

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.

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…

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.

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.

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.

Why would one want to use VeraCrypt volumes over regular LUKS?

Cross platform support is a good reason.

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.

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.

Probably less of a focus on it because VMs have become so cheap and easy, and you can just encrypt a VM.

I am refining an approach that allows for an OS to be hidden via a different method though. Using disk encryption with the key stored in the TPM, and by default booting into a virtualized OS with no hint that it is virtualized, unless a key combo is pressed at the boot screen to boot into the real OS - after a password is entered. Doesn't protect against everything but it can protect against a lot if deniability is the goal.

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.

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).

Veracrypt is a disk encryption tool, not for syncing!

I don't think you've understood my comment.

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.

And propper syncing tools can sync only the changed parts.

Do you know a syncing tool which would work with a VeraCrypt image? (rsync algo doesn't for example)

Works fine with rsync here.

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.

By default if rsync sees any difference in metadata (timestamps), it just copies over the file fresh - first to a temporary file and then renames over the original. To do an in-place update you'd need to specify an arg for that. And even then, it needs to do a full read of both files to compare, so all it saves on is bandwidth.

Syncthing uses block syncing, so I imagine it would work well, although I haven't tried.

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

IIRC this was the fork of the abandoned Truecrypt which had its code verified and basically certified to have no backdoors or major cock-ups, and then given a new (terrible) name before quietly fading into the background…

Truecrypt was really great, and I enjoyed their take on plausible deniability, but haven’t used it since maybe 2006.

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?

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

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.

Why is disabling tivoization a hard no for you?

SIP is a useful bit of extra security that doesn't cause any other issues for me, and there's no need to disable it for encrypted volumes either if I use anything but VeraCrypt.

Not sure if this was ever necessary or when it stopped being necessary, but you definitely don’t need to disable SIP to use VeraCrypt (anymore).

You do need to install macfuse which is effectively closed source, but SIP stays on.

I've been using Truecrypt + syncthing since forever. Serious question: why would I move to veracrypt? It seems just a risk that something breaks.

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/

BitLocker - I'm not going to move to some windows-first software.

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.

On the downloads page [1] the latest release is in sync with Github

[1] https://veracrypt.fr/en/Downloads.html

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.

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.

> 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

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

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.

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

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

Well that's disappointing.

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!

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.

Can it set-up /boot volume encryption and using of TPM for unattended reboots? Thats the deal breaker feature.

I once asked the developers about this and they did not seem to understand what the point of a TPM even is, unfortunately.

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.

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

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.

tough lesson, but i hope you use a password manager now.

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.

Has anyone seen legal cases involving hidden partitions?

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?

“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

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.

We're not taking issue with you calling it a fork, which it is. We're taking issue with you calling it an HOSTILE fork, which it isn't.

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.

Bitlocker is Windows-only

You could use dislocker on Linux.

if the data is important enough just buy a laptop for bitlocker only and then disconnect from the internet after installing it.

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.

It's certainly on Windows 11 Home edition, but it isn't called Bitlocker and has a less powerful GUI than the Pro version.

Only on supported hardware and your key is automatically stored by Microsoft(but can be deleted)

Last part only if you don’t use the CLI.

then buy pro. If the data is important enough, $100 is trivial.

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.

This is wrong. You can set it up with the command line tool which neither sends your key nor do you need an account.

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.

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.

Reply on news.ycombinator.com