[Cryptography] Speeding up Linux disk encryption

[Jerry Leichter]

> ... [In common situations] FDE is a liability, not an advantage, because the concern for most people is data loss rather than protection against a smash-and-grab intended to steal high-level corporate secrets.  I keep getting nagged toenable Bitlocker, which protects against no practical threat that I can think of but ensures that if anything goes wrong I can't plug the SSD into another machine and recover everything that's still recoverable.
> 
> And I'm saying that from having helped with numerous migrations of standard
> and Bitlockered storage media over the years.  With Bitlocker it's always been wipe-and-reinstall, a.k.a. complete data loss.  With non-Bitlocker its
> (almost) always been "all your old files are now available on your D: drive"
> (the exception was where the corruption was too severe to recover more than
> individual files).
> 
> So ironically the only media I'd use FDE with is where the value of the
> contents is low enough that it doesn't matter if they get lost.

A similar debate occurs on the question of whether to encrypt backups.  On the one hand ... what if someone steals your backup?  On the other ... when you need to access the backup, will you remember the key, which you personally haven't used since you stored it on the system - which no longer boots - two years ago?

It's kind of interesting how Apple approaches this.  They support FDE, and it's trivial to enable and use - but not on by default.  Similarly, when you set up a Time Machine backup, you can easily turn on encryption, but you don't have to and it's not the default.  If you set up a Time Machine backup of a disk with FDE turned on but don't encrypt it, you get prompted with an "are you sure?" kind of message, but again it's up to you whether to turn it on.  So they provide the capability for Mac (i.e., relatively sophisticated) users but you have to deliberately choose it.  Same for local backups of iOS devices.  But Cloud backups of iOS devices - which is what the vast majority of iOS users will use, if they do any backup at all - can't be encrypted.  There are ongoing arguments about why this is so - did the FBI lean on Apple to retain access? - but the basic issue is very strong here:  You're likely to get a hundred or more times as many people who lose access to their backup because they've long forgotten the password they chose than people who are exposed in some way because someone got at their unencrypted cloud backups.

(On the other hand, the SSD's in M1-based devices appear to be inherently encrypted using a device-specific key.  This likely super-encrypts any FDE encryption you set.  It appears Apple can get the data out somehow assuming enough of the machine is still alive to get at the keying material, but at the moment there's no publicly known way for anyone else to do it.)

Personally I've been of two minds on the whole thing.  For my work machines which contain my company's property ... absolutely, turn on FDE.  For my own ... I haven't been consistent.  Actual sensitive data on the machine (passwords stored on my KeyChain's, some stuff I put into individually encrypted disk image files) is already encrypted.  I could, if I really wanted, probably arrange for all my stored email to be encrypted by mounting an encrypted disk image file over the mail directory ... but who am I really worried about?  (I do my best not to let sensitive data get into my emails anyway.)  So far, I haven't encrypted any of my (local, on a RAID array inside a ioSafe box) backups.  If I ever decide to back that up to something like Amazon's Glacier I might encrypt it before sending it there, just on general principles....
                                                        -- Jerry