Encrypted persistence partition configuration for a Kali Linux live USB
0 reputation · 12 Jul 2020, 11:18 UTC
0 reputation · 12 Jul 2020, 11:18 UTC
Kali Linux's live USB persistence feature saves changes across reboots on a separate partition labeled persistence. The documented setup leaves encryption to the user: the partition can remain a plain ext4 filesystem unless a LUKS container is created manually, and the persistence mechanism does not enforce encryption by default in recent rolling releases.
The goal is a live USB where saved data — configurations, captured artifacts, stored credentials — survives reboots yet stays unreadable if the drive is plugged into another system. The uncertainty is where the encryption boundary sits: whether the live boot process unlocks a LUKS-formatted persistence partition at boot time, or whether an unencrypted partition is the only configuration the feature reliably supports.
31275 reputation · 12 Jul 2020, 14:10 UTC
Kali Linux's live-boot system (inherited from Debian live-boot) supports LUKS-encrypted persistence partitions. The encryption is optional and not enforced by default in current rolling releases. The live initramfs includes scripts that can unlock a LUKS container labeled 'persistence' at boot time when the kernel parameter persistence-encryption=luks is present or when the partition is detected as LUKS with a matching persistence.conf inside.
cryptsetup luksFormat /dev/sdXn to create a LUKS2 container on the persistence partition.cryptsetup open /dev/sdXn kali-persistence to unlock it.mkfs.ext4 -L persistence /dev/mapper/kali-persistence.persistence.conf with contents like / union to enable full persistence.cryptsetup close kali-persistence. The live system will now prompt for the passphrase on subsequent boots.After booting with the encrypted persistence, verify the setup:
cryptsetup status kali-persistencemount | grep persistence should show a /dev/mapper/ devicedmesg | grep -i crypt to confirm early LUKS unlockThe official Kali documentation still treats encryption as a manual, advanced procedure. Graphical USB creators do not enable it automatically. In Secure Boot environments, the unsigned initramfs hooks that prompt for the LUKS passphrase may be blocked unless the bootloader and kernel are properly enrolled. Rolling-release changes to live-boot or cryptsetup can alter the exact hook names or parameter syntax without notice.
Action needed: Test with a deliberately wrong passphrase to confirm the boot drops to an emergency shell rather than mounting an unencrypted fallback.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.