2

So I have a few questions.

1) Would encrypting a SED-enabled drive with LUKS have no positive effects on a drrive? My guess is that it would provide a double-layered encryption as a positive, however I’m not sure, and that’s why I’m here.

2) If there are positive effects, how do these weigh out with the possible negative effects? To me it would seem like slowing down a drive, however again I’m not sure.

3) If there are no/little positive effects, should I buy a SED-enabled drive or encrypt one with LUKS?

ut793
  • 95
  • 1
  • 11

2 Answers2

3

The advantages of running both are minimal, although the answer as to the better solution depends on your goal.

SED technology is built into the drive, so presumably OS agnostic. On the other hand its closed source and some versions have had major security flaws. Its also full disk. Unsure if LUKS allows you to tick some compliance boxes that SED will tick if you are buying for a company that needs it.

LUKS, on the other hand is open source, OS specific and requires CPU - Its worth noting though that if your CPU is modern (eg has Intel AES-NI support this overhead is low) Another thing to be aware of is that LUKS is typically not full disk, its full partition.

Double layered encryption can be a positive, but may not be worth the complexity - especially if using LUKS. On the other hand, if you have unencrypted data, self erase offered by SED drives could be valuable.

Only you can judge if the cost benefit is worth an SED drive in your case.

davidgo
  • 68,623
  • 13
  • 106
  • 163
0

As a complement to davidgo's answer :

Using SED in addition to LUKS is also an EASY way to encrypt the boot partition (doable with LUKS alone, but not always straightforward), and is the ONLY way to encrypt the EFI partition.

Plus, if I understand correctly, a SED drive is already encrypted anyway. The thing is that its encryption key is not protected out of the box by an authentication key. Once you've set up your authentication key, then the encryption key is protected. So, by default, you are using SED's encryption anyway, only without having protected its encryption key.

Thus, the only question when you have a SED drive is : do I want to type in another password ? Using SED (e.g., setting up an authentication key) with LUKS can be interesting in some cases, for example if you choose to auto-decrypt your LUKS by storing the key in TPM. That way your disk is protected by your long LUKS passphrase, but you don't have to type it, you just type in your shorter SED password (I believe SED have an anti brute force mechanism).

Although, I believe since Systemd v251 the TPM can also be protected by a PIN code, so you can have the same functionalities with LUKS only (store your LUKS key in TPM, and protect it with a shorter password - I believe TPMs also have anti brute force mechanisms).

ChennyStar
  • 190
  • 1
  • 6