The sda3_crypt partition is 118.5G, so does that effectively mean that my entire drive is encrypted, including unallocated space (excluding the boot partition)?
Assuming the drive was randomized before or during the initial encryption, yes. The entirety of your third partition is encrypted. If you started using encryption and just formatted your disk, there may be leftover traces from the previous, unencrypted install. However files that are deleted in the encrypted partition, deallocating their blocks, will remain encrypted.
This is not necessarily the case for solid state drives that support (and use) TRIM, however. TRIM support allows the OS to send a signal to the drive to zero unallocated sectors, because the SSD firmware can make better optimization decisions when it knows what blocks are free and what blocks are not (something it cannot know without the OS telling it, due to the encryption). In that case, unallocated spaces is erased and zeroed. This can allow someone to know which blocks are unallocated on an encrypted drive, by seeing which ones are zeroed. They will not be able to know what the blocks previously contained, both because it was zeroed, and because it was encrypted. There is a great blog post on the issues with SSDs that support TRIM and encryption.
In terms of the boot partition, am I correct in that it is possible to keep it on a USB stick? What happens when you try to boot the OS without the USB drive, then?
Yes, you can keep the boot partition on any device that the BIOS supports booting from. If you try to boot without the USB drive, the behavior depends on your BIOS settings. It may attempt to boot from other plugged in media, or may say that no bootable medium was found and to press F12 to reboot or something of that sort. The effect would be the same as if you took out all drives.
Lastly, does the output of lsblk indicate that my swap partition is encrypted?
Yes it does. You are using LVM on top of
sda3_crypt, which is a method of, among other things, creating virtual partitions. The output shows that your encrypted device mapping is split into two virtual partitions (called volume groups in LVM terminology):
user--vg-swap_1. This means LVM was set up on the encrypted partition, so all volume groups it creates will also be encrypted.
My question is directed at guest, who answered this post. You say "Assuming the drive was randomized before or during the initial encryption, yes. The entirety of your third partition is encrypted."
I assume you mean that the drive was wiped with zeros before the encryption was performed. But my question is, is it okay to wipe an SSD with zeros for "safer" encryption? Won't that reduce the SSD's lifespan?
I mean the drive was wiped with random data before it was used with encryption. Encrypted zeros look random, so if you randomize a device and then encrypt it, no one without the key can tell which sectors have all zeros. If you zero it before encrypting, then you may have gotten rid of previous unencrypted data, but you are revealing exactly what sectors are in use. This is often a necessary evil with SSDs, due to TRIM being important for performance and lifespan.
A single "cell" in an SSD can handle between 2,000 and 10,000 erase cycles. I believe some even get around 100,000. This means you could overwrite the device that many times before severe risks of failure occur. Not to mention, they have some extra, hidden storage to prevent wear, called overprovisioning space.
You do not have to write zeros to the entire SSD. You can zero it by issuing a manual TRIM command, which tells the low-level firmware to zero everything. This can be nearly instant, because it is a separate action from writing. On Linux, you can use the
hdparm command. From the manpage:
For Solid State Drives (SSDs). EXCEPTIONALLY DANGEROUS. DO NOT
USE THIS OPTION!! Tells the drive firmware to discard unneeded
data sectors, destroying any data that may have been present
within them. This makes those sectors available for immediate
use by the firmware's garbage collection mechanism, to improve
scheduling for wear-leveling of the flash media. This option
expects one or more sector range pairs immediately after the
option: an LBA starting address, a colon, and a sector count
(max 65535), with no intervening spaces. EXCEPTIONALLY DANGER‐
OUS. DO NOT USE THIS OPTION!!
E.g. hdparm --trim-sector-ranges 1000:4 7894:16 /dev/sdz
Don't be scared about the apocalyptical warnings that are so common to that one program's documentation. All it is trying to address is the risk of losing data with this flag. You would want to set the starting address to 0, and the sector count to the total size of your drive. This will quickly erase everything without shortening the drive's lifespan as much as if you write directly to it.