this post was submitted on 20 May 2025
35 points (97.3% liked)

Linux

54492 readers
535 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
35
Full Disk Encryption on SSD (Debian) (feddit.org)
submitted 1 week ago* (last edited 1 week ago) by [email protected] to c/[email protected]
10 comments fedilink hide all child comments
 

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

top 10 comments
sorted by: hot top controversial new old
[–] [email protected] 11 points 1 week ago

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.

[–] [email protected] 4 points 1 week ago

How does the encryption affect the wear-leveling of the SSD and what should be considered to ensure a safe encryption?

LUKS, or rather Device Mapper for crypto devices does not enable trim by default, you need to enable it separately.

https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)

the LUKS wiki also has some general tips, and some for SSDs specifically: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions

[–] [email protected] 4 points 1 week ago

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.

[–] [email protected] 3 points 1 week ago (1 children)

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.

[–] [email protected] 1 points 1 week ago* (last edited 1 week ago) (1 children)

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!

[–] [email protected] 1 points 1 week ago

It's safe.

[–] [email protected] 2 points 1 week ago (1 children)

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.

[–] [email protected] 2 points 1 week ago (1 children)

That is block based encryption

isn't all the disk encryption standards supported by cryptsetup are like that? so LUKS1, veracrypt, bitlocker, etc

[–] [email protected] 1 points 1 week ago* (last edited 1 week ago) (1 children)

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.

[–] [email protected] 2 points 1 week ago

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.