How to Re-Encrypt LUKS Storage and Upgrade Cipher Suites in Ubuntu Using cryptsetup reencrypt

Block device encryption via Linux Unified Key Setup (LUKS) forms the primary defense against physical data extraction on Ubuntu workstations and enterprise servers. Historically, changing the underlying cryptographic cipher, altering volume master keys, or encrypting an existing plaintext block device required a destructive reformat and complete restoration from backup. With modern LUKS2 and the cryptsetup reencrypt utility, system administrators can perform seamless in-place cryptographic transitions, cipher upgrades, and master key rotations on live or unmounted block devices without wiping filesystem data.

Understanding LUKS2 Online and Offline Re-Encryption Architecture

LUKS2 incorporates advanced metadata resilience, including redundant JSON headers, secondary keyslot allocations, and cryptographic digest verification. The re-encryption engine operates through a crash-safe sliding window algorithm:

• Hotzone Buffering: The re-encryption engine writes a chunk of data (the hotzone) to a designated log or resilience sector, decrypts the block with the existing master key, encrypts it using the new cipher or key, and writes it back to the target storage.
• Crash Resilience: If power failure or a kernel panic occurs mid-operation, the LUKS2 header retains exact byte offset markers and checksums. Upon reboot, running cryptsetup reencrypt --resume-only recovers the interrupted segment without data corruption.
• Online vs Offline Modes: Starting in modern Ubuntu releases with kernel device-mapper support, unmounted devices can undergo offline re-encryption at maximum throughput, while mounted active filesystems can be re-encrypted online using kernel dm-crypt dm-linear overlays.

Prerequisites and Header Backup

Before initiating any block-level cryptographic operation, backing up the LUKS header is mandatory. Because re-encryption modifies metadata areas and key digests, a corrupted header could render the underlying filesystem permanently inaccessible.

# Identify the target block device
lsblk -f

# Create a secure binary backup of the LUKS2 header
sudo cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file /root/luks-header-nvme0n1p3.bak

# Verify the header backup file integrity
sudo cryptsetup luksDump /root/luks-header-nvme0n1p3.bak

Ensure the target device runs LUKS2. If the partition uses legacy LUKS1, upgrade the header format prior to re-encryption:

# Check the current LUKS header version
sudo cryptsetup isLuks --verbose /dev/nvme0n1p3

# Upgrade legacy LUKS1 metadata to LUKS2 (requires unmounted partition)
sudo cryptsetup convert /dev/nvme0n1p3 --type luks2

Rotating the Master Encryption Key

Rotating passphrase keyslots does not alter the underlying master key that encrypts physical sectors. If a master key is suspected of being compromised, rotating the master key itself is essential. cryptsetup reencrypt generates a new volume master key and re-encrypts all data blocks without changing the user passphrases:

# Unmount active filesystems and close mapped dm-crypt targets
sudo umount /mnt/securedata
sudo cryptsetup close securedata_mapped

# Execute master key re-encryption
sudo cryptsetup reencrypt /dev/nvme0n1p3

The command prompts for an existing passphrase, generates a fresh random master key, and streams through the entire block device, updating the status progress indicator in real time.

Upgrading Ciphers and Hash Algorithms

Legacy deployments frequently rely on 128-bit or 256-bit AES-CBC or standard AES-XTS with SHA-1 or SHA-256 key derivation functions (KDF). To comply with modern post-quantum and high-security compliance mandates, you can re-encrypt the volume to 512-bit AES-XTS (aes-xts-plain64) combined with Argon2id memory-hard hashing:

# Re-encrypt partition with AES-XTS-512 and Argon2id KDF
sudo cryptsetup reencrypt /dev/nvme0n1p3 \
    --cipher aes-xts-plain64 \
    --key-size 512 \
    --hash sha512 \
    --pbkdf argon2id \
    --pbkdf-memory 1048576 \
    --pbkdf-parallel 4

The parameters enforce strict hardening against GPU-accelerated brute-force attacks by allocating 1 GB of RAM and 4 compute threads during keyslot evaluation.

Encrypting an Existing Plaintext Partition In-Place

One of the most powerful capabilities of cryptsetup reencrypt is converting an unencrypted filesystem (such as Ext4 or XFS) into a fully encrypted LUKS2 partition without reformatting or transferring data to intermediate media.

First, shrink the filesystem slightly to allocate space at the beginning of the block device for the LUKS2 header (typically 16 MiB to 32 MiB):

# Check filesystem integrity before resizing
sudo e2fsck -f /dev/sdb1

# Shrink the filesystem by 64 megabytes
sudo resize2fs /dev/sdb1 950G

# Re-encrypt the plaintext block device into a LUKS2 container
sudo cryptsetup reencrypt --encrypt --type luks2 --reduce-device-size 32M /dev/sdb1

Once re-encryption completes, open the new encrypted mapping and expand the filesystem to consume all available encrypted boundary space:

# Open the newly encrypted block device
sudo cryptsetup open /dev/sdb1 secure_storage

# Expand the Ext4 filesystem to fill the container
sudo resize2fs /dev/mapper/secure_storage

# Mount the verified encrypted volume
sudo mount /dev/mapper/secure_storage /mnt/securedata

Resuming Interrupted Re-Encryption Sessions

If a server reboots or encounters an unexpected disconnection during a multi-terabyte re-encryption operation, the device-mapper driver pauses the volume to prevent data divergence. Inspect the recovery state and resume execution safely:

# Check the current re-encryption progress and state
sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -A 10 "reencrypt"

# Resume the re-encryption process
sudo cryptsetup reencrypt --resume-only /dev/nvme0n1p3

The utility reads the checkpoint markers stored in the secondary JSON header and immediately resumes data processing from the exact interrupted block sector.

Auditing and Validating Active Encryption Parameters

After re-encryption completes, verify that the cryptographic metadata, cipher specifications, and keyslots align with your target security posture:

# Query complete LUKS header metadata
sudo cryptsetup luksDump /dev/nvme0n1p3

# Inspect active kernel device-mapper status
sudo cryptsetup status secure_storage

The output confirms the active cipher specification (e.g., aes-xts-plain64), keysize (e.g., 512 bits), and active sector offsets, confirming that the block device is completely secured under the upgraded cryptographic standard.