🎯 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 cryptsetup to 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/sdX with the correct device (check carefully with lsblk)

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:

  1. Existing passphrase (to prove authorization)
  2. 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 gocryptfs to 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) using rsync over 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 with ssh-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