🎯 Goal
This week covers protecting local data at rest with encrypted filesystems and containers. The tools are LUKS, cryptsetup, gocryptfs, and veracrypt, and you’ll practice encrypting backups using tar and rsync over SSH.
🌱 New to this? If the command line feels like a lot, Privacy 101 covers encrypted storage with a graphical, beginner-friendly walkthrough (VeraCrypt, Cryptomator) first: Privacy 101 Week 9: Encrypted Storage →
1. Why Encrypt Data at Rest?
- Prevent access if your device is lost, stolen, or seized
- Protect sensitive logs, identity files, password stores
- Essential for laptops, USB drives, and backups
2. Full-Disk and Partition Encryption with LUKS
What Is LUKS?
- Standard for Linux disk encryption
- Uses
cryptsetupto manage encrypted partitions - Key benefits: strong encryption, passphrase support, keyslots
WARNING
The following examples will erase data. Only do this on test devices or virtual machines.
Setup a LUKS Encrypted Volume
sudo cryptsetup luksFormat /dev/sdX
- Replace
/dev/sdXwith the correct device (check carefully withlsblk)
Open the Encrypted Device
sudo cryptsetup luksOpen /dev/sdX secure_volume
🧱 Format and Mount It
sudo mkfs.ext4 /dev/mapper/secure_volume
sudo mkdir -p /mnt/secure
sudo mount /dev/mapper/secure_volume /mnt/secure
sudo chown $USER: /mnt/secure
The chown gives you write access to the new filesystem, whose root is owned by root.
Close It When Done
sudo umount /mnt/secure
sudo cryptsetup luksClose secure_volume
3. Encrypted Containers: gocryptfs
Why Containers?
- Portable, simple, user-space encryption
- Encrypted files are stored inside a directory, not a block device
Install gocryptfs
sudo apt install gocryptfs
Create an Encrypted Container
mkdir ~/Secure
mkdir ~/Secure.encrypted
gocryptfs -init ~/Secure.encrypted
Enter a strong passphrase.
Mount It
gocryptfs ~/Secure.encrypted ~/Secure
Now use ~/Secure as a decrypted view.
Unmount
fusermount -u ~/Secure
🛡 4. Graphical Alternative: VeraCrypt (Cross-Platform)
- GUI tool (and CLI) for creating encrypted containers or full disks
- Runs on Linux, macOS, and Windows
- https://www.veracrypt.fr
Example CLI Workflow
veracrypt --text --create container.vc
Follow the prompts to choose:
- Size, algorithm (AES), password, filesystem
- Mount with:
veracrypt --text --mount container.vc /mnt/veracrypt1
🪦 4b. Tomb - GPG-Protected LUKS Containers
What is Tomb?
Tomb combines LUKS encryption with GPG key management for “stealthy” encrypted storage:
- LUKS container disguised as regular file
- Key protected by GPG (can use smartcard/YubiKey)
- Supports key hiding in images (steganography)
Install Tomb
sudo apt install tomb
Or from source: https://github.com/dyne/Tomb
Create a Tomb
Tomb refuses to forge, lock or open while unencrypted swap is active. Check with swapon --show. For this session you can run sudo swapoff -a (re-enable with sudo swapon -a), or encrypt your swap; on a low-RAM machine swapoff can fail or cause trouble. Only pass --ignore-swap if you accept that secrets could be written to disk.
# 1. Create the tomb file (100MB example)
tomb dig -s 100 secrets.tomb
# 2. Generate a key file and encrypt with GPG
tomb forge -g -r <your-gpg-id> secrets.tomb.key
# 3. Lock the tomb with the key
tomb lock -g secrets.tomb -k secrets.tomb.key
With -g, forge encrypts the key file to your default GPG public key (or the one given with -r), so forge itself asks for no passphrase. GPG’s pinentry will ask for your GPG key passphrase when the key is decrypted, which happens at tomb lock and again at each tomb open. Without -g, forge asks you to choose a passphrase for the key file instead. There is no separate passphrase for the tomb itself.
A key forged with -g needs -g on every command that uses it: lock, open and bury.
Open (Mount) a Tomb
tomb open -g secrets.tomb -k secrets.tomb.key
Default mount point: /media/secrets
Close a Tomb
tomb close secrets
Or close all open tombs:
tomb close all
Advanced: Hide Key in Image (Steganography)
Requires steghide: sudo apt install steghide. With -g, bury also prompts for a separate steganography password that protects the key inside the image.
# Bury the key inside an image
tomb bury -g -k secrets.tomb.key photo.jpg
# Later, exhume it when needed
tomb exhume photo.jpg -k extracted.key
# Use the buried key
tomb open -g secrets.tomb -k photo.jpg
Even if someone finds the tomb file, they won’t know where the key is hidden.
🔑 4c. LUKS Key Management (Multi-User Access)
Why Multiple Keyslots?
LUKS supports multiple keyslots — each can have a different passphrase (LUKS2, today’s default format, allows up to 32; legacy LUKS1 allows 8):
- Share encrypted drive with colleagues (each has own password)
- Emergency recovery passphrase
- Remove a passphrase you no longer want to accept
Check Current Keyslots
sudo cryptsetup luksDump /dev/sdX
Look for the “Keyslots:” section (LUKS2). Each used slot is listed by number, for example “0: luks2”. Empty slots are not listed. On legacy LUKS1 volumes you will instead see “Key Slot 0: ENABLED” or “DISABLED” lines.
Backup LUKS Header
Before experimenting with keyslots, always backup the LUKS header:
sudo cryptsetup luksHeaderBackup /dev/sdX --header-backup-file luks-header-backup.img
Store this file somewhere safe (encrypted USB, offline storage).
Add a New Keyslot
sudo cryptsetup luksAddKey /dev/sdX
You’ll need:
- Existing passphrase (to prove authorization)
- New passphrase to add
Remove a Keyslot
sudo cryptsetup luksRemoveKey /dev/sdX
Enter the passphrase you want to remove.
WARNING: Don’t remove the last keyslot or you’ll be permanently locked out!
Removing a keyslot stops that passphrase from opening this header. It does not change the volume key. Anyone who already had the key or a copy of the header (including your own old header backups) can still get in. After removing a passphrase, make a fresh header backup and destroy the old ones. If you must truly revoke someone, re-encrypt the volume with cryptsetup reencrypt (LUKS2) so it gets a new volume key, or move the data to a new container.
Restore LUKS Header (Emergency Recovery)
If LUKS header gets corrupted:
sudo cryptsetup luksHeaderRestore /dev/sdX --header-backup-file luks-header-backup.img
Without this backup, a damaged header means the data is gone.
5. Encrypted Backups with tar, gpg, and rsync
🗃 Archive + Encrypt a Folder
tar czf - ~/Secure | gpg -c -o backup.tar.gz.gpg
Decrypt + Extract
gpg -d backup.tar.gz.gpg | tar xz
🔁 rsync Over SSH (Encrypted Transfer)
Needs an SSH key and a remote host you can log into (Week 5 covers key setup). No remote yet? Back up locally instead: rsync -av ~/Secure.encrypted/ /media/usb/backups/.
rsync -avz -e "ssh -i ~/.ssh/id_ed25519" ~/Secure.encrypted/ user@remote:/backups/Secure.encrypted/
Sync the .encrypted directory, never the mounted ~/Secure view. SSH encrypts the transfer, and gocryptfs keeps the remote copy encrypted at rest, so no mount is needed. gocryptfs.conf sits inside the cipher directory, so rsync carries it along; also store the master key printed at -init somewhere safe.
Use --delete to mirror:
rsync -avz --delete -e "ssh -i ~/.ssh/id_ed25519" ~/Secure.encrypted/ user@remote:/backups/Secure.encrypted/
6. Journal & Git Commit
Reflect on Week 4
echo "Week 4: Encrypted volumes with LUKS, tested gocryptfs and Tomb, practiced keyslot management and LUKS header backups, created secure encrypted backups." >> notes/week4_journal.md
Git Commit
git add .
git commit -S -m "Week 4 - Disk encryption, containers, Tomb, and backup security"
✅ Week 4 Checklist
- Created a LUKS encrypted volume with
cryptsetup - Used
gocryptfsto make a lightweight encrypted directory - Explored VeraCrypt for GUI encryption
- NEW: Created a Tomb with GPG-protected keys
- NEW: Practiced LUKS keyslot management (add/remove)
- NEW: Backed up LUKS header for emergency recovery
- Encrypted a backup with
tar+gpg - Synced the gocryptfs ciphertext directory (
Secure.encrypted) usingrsyncover SSH (optional, needs a remote host) - Updated journal and signed Git commit
🔜 Up Next: Week 5 Preview
- SSH deep dive: key-based authentication, server hardening, UFW firewall
- Port forwarding, tunneling and ProxyJump
~/.ssh/config,scp, managing multiple keys withssh-agent
Notes
- Always store encryption passphrases in a secure password manager
- Use unique, long passphrases for every encrypted container
- Keep a LUKS header backup: a corrupted header without one means permanent data loss
- Tomb’s steganography feature adds plausible deniability (key hidden in innocent image)
- Multiple LUKS keyslots enable shared access without sharing passwords
- Always unmount encrypted filesystems before powering off or suspending your device
- Test your recovery procedures BEFORE you need them in an emergency