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.
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'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
I'm a fan of gocryptfs [1]/cppcryptfs (Windows implementation) [2], they also have a fairly unbiased comparison [3] with other solutions, including CryFS.
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.
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)
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.
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.
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.)
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.
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...
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.
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.
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.
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.
> 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.
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.
> 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.
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.
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 :)
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.
> 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.
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).
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.
> 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.
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.
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.
> 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 …
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.
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.
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.
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.
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.
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.
> 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.
> 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?
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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/
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.
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.
> 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.
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
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.
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].
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.
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.
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.
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.
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.
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.
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