from sp3ctre@feddit.org to linux@lemmy.ml on 20 May 11:59
https://feddit.org/post/12769056
Hi everyone,
as my thread from yesterday about shredding SSD’s the right way already was very helpful, another follow-up topic came to my mind, which may also be interesting for me and maybe others too.
Since many PC’s often use SSD’s and less harddrives nowadays it may be interesting to discuss the full-disk encryption of it.
First of all some questions, which came to my mind:
- Does the encryption of a SSD decrease its performance (read/write-speed) significantly?
- How does the encryption affect the wear-leveling of the SSD and what should be considered to ensure a safe encryption?
- Will functionalities like hibernation still work? Are maybe other functionalities affected in a negative way?
I already successfully full-disk encrypted my old laptop (harddrive) with the instructions from StackExchange. My computer has a 1TB SSD + 1TB harddrive and I wish to encrypt completely everything, that’s not technically necessary. I want to use Debian as my distro. Could this instruction work the same way as with harddrives?
I’m interested in your knowledge about this.
~sp3ctre
threaded - newest
I’m confused by some of your questions, but it seems you are thinking that HDD vs SSD in the context of encryption is different, but it is functionally the same. Any perceived performance difference by percentage on HDD would be the same or better on SSD.
I don’t think you’d perceive any slowdowns from encryption unless you’re doing very specific types of work and hitting the disk util hard, and even it would probably only be a few percentage points of difference between encrypted and unencrypted.
You can find versions benchmarks online to compare different filesystem types and settings compared.
Hehe, no stupid questions I guess! When googling about this type of stuff, I often stumble across some claims I simply cannot verify myself. Some people say it’s unsafe, some people say it slows down everything and so on and some answers are from >10 years ago, so I feel the need to clarify what’s the status quo. Thanks for your view on that!
It’s safe.
It should work almost exactly the same as hard drive encryption. In my experience, the read/write overhead from encryption is negligible. Encryption shouldn’t affect wear-leveling, and it’s still possible to TRIM the drive to discard any unused blocks (although TRIM may leak some filesystem metadata).
If you want to ensure any previous unencrypted is erased on the SSD, consider formatting and trimming it before encryption (using something like blkdiscard). Hibernation should still work, it will just prompt you for your encryption passphrase then resume your session. I’m not sure about any lost functionality, but it’s been seamless for me.
Depending on your threat model, keep in mind that full disk encryption typically leaves the boot partition (usually containing the kernel, initrd, and bootloader) unencrypted since it’s needed to boot the system. This can leave you susceptible to evil maid attacks or modifications from another operating system (if dual booting). For most people though I assume this shouldn’t be an issue.
I am using MX Linux (Debian based) and at install I chose FDE, just with the GUI it’s easy to have LUKS+btrfs, nothing special to do. Encryption is done by hardware, your CPU has AES instructions that can encode/decode gigabits/s and is not a bottleneck at all.
I read this week that one should use LUKS2 on SSDs. That is block based encryption so some information is leaked, like how much data is on the drive and how much changes. But I guess this makes it easier for the SSD to manage its health.
isn’t all the disk encryption standards supported by cryptsetup are like that? so LUKS1, veracrypt, bitlocker, etc
As far as I understand it with LUKS1 the whole partition is filled with random looking data and when something changes it does so at random points which doesn’t let you see how much data really changed or how much is actually useful data.
But my knowledge is really really spotty, so I might have understood something incorrectly.
hmm I’m not sure, I think that would throw sequential read/write performance out of the window, surely on HDD, maybe even on SSD to an extent. but, such a thing can probably be added with a device mapper device.
LUKS, or rather Device Mapper for crypto devices does not enable trim by default, you need to enable it separately.
wiki.archlinux.org/title/Dm-crypt/Specialties#Dis…
the LUKS wiki also has some general tips, and some for SSDs specifically: gitlab.com/cryptsetup/…/FrequentlyAskedQuestions