Storage encryption

[Zucca]

being a good boy and reading all the arch linux wiki before digging into my new arch linux box...
Nice reading and a very good learning curve so far....

Stumbled today in this
https://wiki.archlinux.org/title/Security#Storage

I wonder what is your opinion on it....

I mean on laptop encrypting the disks seems reasonable to me, but in a workstation box at home... it seems overkill to me.

[ataradov]

On laptops I always encrypt. On PCs I have not done it because of possible reliability and recovery issues, but I have done it for so long on laptops that on the next install on the PC, I'll likely do it as well.

I also had performance concerns, but that does not seem to be an issue at all.

Home PCs are less of an issue, but they are also subject to theft. It is not likely, but encryption does not seem to hurt anything, so why not?

[dobsonr741]

Good read on how Apple does it: https://support.apple.com/guide/security/hardware-security-overview-secf020d1074/1/web/1

[SiliconWizard]

I just installed my new workstation with Arch over the weekend, and at this point I've migrated pretty much everything I needed to.

I did not use encryption at this point. But that's something to consider.
Main points to weigh in: performance, as ataradov pointed out. Even though it's not much of a problem these days. But could be depending on your particular use case.
But, most of all, it's up to you to consider whether it's more important that *you* never possibly get "kicked out" of your own data, or if it's more important that someone else never accesses it.
Very personal question - unless of course you're bound by a company's policies.

[bitwelder]

In general I'd go for encryption for all work-related laptops, but not for work-related desktop/workstation/servers.
Main reason for not encrypting is avoiding loss of performance

For not-fully-encrypted disks, one possible option could be to just have a small 'secure' filesystem that is encrypted, and e.g. unlocked manually by the user.

[Nominal Animal]

I fully agree with bitwelder, above.

For partially encrypted systems, I have used two approaches:

• Encrypted per-user secure data partition, symlinked from specific directories (~user/.ssh/, ~user/.thunderbird/, ~user/.mozilla/, etc.) to keep only those directories encrypted.
• Encrypted per-user home partition, with non-sensitive directories (like ~user/Downloads/) symlinked to a common non-encrypted storage partition with per-user directories.

Just periodically check that the symlinks have not been replaced by unencrypted directories.  I used Zenity to pop up a warning if that ever happened, but it never did to my recall (except when I did it myself by accident, for example by extracting an archive to my home directory).  The former requires a bit more effort to set up.

In the Linux minilaptop era over a decade ago (Acer Aspire One, anyone?), I used to keep my browser profile (and 64MB cache) on a tmpfs, i.e. a ramdisk, that would be tarballed at close of session (last browser window closes) and extracted and set up at open of session (first browser window opening).  The one I had (still have) used a slooow 2.5" IDE drive, which was really a bottleneck for web browsing.  Made it rather nice for browsing at that time, really.

[golden_labels]

When I was setting up this system, I was much less experienced and encryption was not as well supported as it is now. So back then I did not encrypt my primary hard drive. It stayed like this until today due to logistic limitations. Only some particular things are separately encrypted and mounted, as well as swap. Now I would certaily use a different approach. Data drives are now encrypted.

For computers, where booting up is interactive or are fully under my control: yes. This ensures the storage medium can be securely discarded without much additional effort.

For remote VPS: no. In this case I must trust the service provider to do things properly. Otherwise I would need to either keep the key with encrypted data (almost pointless) or provide the key remotely (unreliable). The exception is swap, which can use a random key.

There is tiny risk associated with losing the encryption key. But IMO it shouldn’t be treated in a manner different than e.g. a random hardware failure. Just have backups of both your data and the key.

[Zucca]

Thanks everybody, everything seems reasonable for me too now.
Why having an extra layer of security if it is not needed?
And yes even if the performance losses are small, they are just irritating if not necessary.

BTW now that I am upgrading my workstation box, having not encrypted storage make the d(s)ata transfer between boxes a piece of cake.

Always a pleasure to read this computer section on the EEVBlog!

[apelly]

If you don't encrypt everything then whatever is encrypted must be interesting.

Just encrypt everything.

[SiliconWizard]

There is tiny risk associated with losing the encryption key. But IMO it shouldn’t be treated in a manner different than e.g. a random hardware failure. Just have backups of both your data and the key.

Do you encrypt your backups?
What about the keys?

[golden_labels]

Why having an extra layer of security if it is not needed?

With that mindset, answering is hard. You can’t expect anybody to deliver an argument, that contradicts your original assumption in a model based on that assumption.

And yes even if the performance losses are small, they are just irritating if not necessary.

For a few years now it’s likely your HDD or SSD does full-disk encryption anyway. You can only choose if you want to use your own key or not, and if you want to use an auditable solution or trust the vendor.

BTW now that I am upgrading my workstation box, having not encrypted storage make the d(s)ata transfer between boxes a piece of cake.

How does encryption affect that process?

Do you encrypt your backups?

If the content was encrypted originally, so are backups. Yes.

What about the keys?

Yes, I do. The ultimate key is a 64-bit passphrase. This can be extracted using rubber-hose cryptoanalysis, a keylogger or social engineering attacks. 23 bits are backed up in cleartext, in case my memory fails to the point I should need a hint. If even the hint fails, not being able to perform decryption is going to be the least of my problems.

Did you want to make some statement with “:popcorn:”? If yes, perhaps be more explicit: makes responding much easier.

[Nominal Animal]

Thanks everybody, everything seems reasonable for me too now.
Why having an extra layer of security if it is not needed?

In my case, my own data and stuff isn't worth encrypting, but when I'm helping others, I take all the precautions of not leaking their data, regardless of whether they consider it worth encrypting or not.

If I keep any backups of others' data during helping – I delete the backups always afterwards –, I do it on physically secured external storage.

And yes even if the performance losses are small, they are just irritating if not necessary.

In my case, even on a fast SSD, it is neglible.  That is, I cannot tell whether the data I'm accessing is encrypted or not.

My own backups are mostly source code and emails, and I don't encrypt those.  (Any emails with proprietary information are moved to the abovementioned external storage and deleted from my mailbox.)

Why so "paranoid", one might ask?  Because it is a very easy way to completely ensure I'm not the weakest link, security wise.  Nowadays it is second nature, and not a bother at all.  When traveling, I always use a secondary laptop (one I can afford to lose) with a pre-prepared, initially completely wiped one, that contains only the minimal amount of information I'll need.  This also means that if e.g. border control or customs wants full access to it, I have no problem with that.

I also keep my passwords in plaintext in a 2D array of characters, where the password is read in a certain orientation (not in a straight line in any specific direction or starting from a specific position).  The width and height can even be smaller than the length of the password.  While this is not "secure" in the way encryption is secure, it is sufficient to stop any casual intrusion.  Anyone with the werewithal or resources, can always just put a gun to my head and force me to decrypt the data, so there is no such thing as absolute security.

On servers, my preferred security measures step up a couple of notches, though, but that's a separate topic.  I'll just mention that there, leaving an immutable audit log of privileged accesses (traceable to a human account) is paramount.  Missteps, excesses and intrusions will happen because we're human, and when they do, an immutable audit log is often the only thing to find out what happened, and to deal appropriately with the people involved.  (Many CxO's hate this, because it makes it impossible to throw a scapegoat underling under the bus when they themselves err.)

[elagergren]

Selectively encrypting things is more effort than it’s worth. Just encrypt everything.

[DrGeoff]

Just use FIPS140-2 SED's and set the key to something other than the default key.
Everything is then encrypted on the drive using hardware/firmware on the drive controller.
There is no change in performance since the default key performs encryption of the contents anyway.
Need to erase the drive? Set a random key.

[madires]

It depends on the risks involved. So I wouldn't say you should always encrypt your disks. But if there are good reasons to do so, then go for it. BTW, if you encrypt your data/disks then make sure that your family is able to access the data/disks in case anything bad happens to you.