Windows WSL2 and LUKS

wsl-luks.md

If you have a LUKS-encrypted partition on another disk, it's easy to mount it inside WSL.

List your disks:

> wmic diskdrive list brief

Mount the whole disk inside WSL (using --bare so WSL doesn't attempt to mount it automatically):

> wsl --mount \\.\PHYSICALDRIVE1 --bare

Now inside WSL, check the device name of the mounted disk (something like /dev/sd*):

$ dmesg | tail

Open the LUKS device (it'll prompt for your passphrase):

$ sudo cryptsetup luksOpen /dev/sdd3 my-encrypted-disk

And mount it somewhere:

$ sudo mount /dev/mapper/my-encrypted-disk /somewhere

Avoid mounting on /mnt because that's usually used by WSL itself to mount your C: drive.

Hello,

I wanted to express my gratitude to you for sharing the information on how to mount a cryptsetup in WSL in the most simple way that I found online. Thanks to your guidance, I was able to effortlessly execute the "luksopen" command and mount my LVM partition, which uses the ext4 file system – just as I'm accustomed to doing. I've streamlined the process by directly running 'commands' in wsl.exe within a PowerShell script, and it even worked seamlessly with a GPG-encrypted keyfile.

I truly appreciate your help. Thank you very much! WSL going strong

Cipher used over here: twofish-xts-plain64 - works fine to decrypt drive even if the twofish module seems missed in in /proc/crypto in my wsl2 setup.

⚠️ NOTE

This has nothing to do with the original post. This is just a warning message for everyone testing LUKS with WSL. If you're seeing this, consider yourself warned. Backup your LUKS header NOW!

Important Update: Cautionary Advisory on Using WSL with Multiple LUKS-Encrypted Drives

For those diving into integrating WSL with cryptsetup and LUKS-encrypted drives, I cannot stress enough the paramount importance of backing up the LUKS header. I recently encountered an issue where Windows inadvertently introduced a 16MB GPT header to my drive. This action put my entire 16TB drive at risk.

This anomaly presented itself upon connecting a Funtoo SSD, housing three partitions:

1. BIOS_GRUB
2. Boot partition
3. Rootfs on LUKS2 encrypted with a GPG key.

Upon further examination, I identified that this GPT overwrite potentially stemmed from interactions between the SSD and a connected USB drive. My proactive decision to back up the LUKS header was the sole reason I managed to restore and access my data. Without this precaution, the outcome might have been irrevocably dire.

Should you be considering a similar WSL setup, I earnestly urge you to make a LUKS header backup prior to any integration or modification steps. The inherent risks are significant, and a pre-emptive backup could be the pivotal factor between a successful recovery and irreplaceable data loss.

Technical Insight without modifcations:

t&fh
TCPAu2
r,fh
fSfSfUfh
Invalid partition table
Error loading operating system
Missing operating system
EFI PART
{"keyslots":{"0":{"type":"luks2","key_size":64,"af":{"type":"luks1","stripes":4000,"hash":"sha512"},"area":{"type":"raw","offset":"32768","size":"258048","encryption":"aes-xts-plain64","key_size":64},"kdf":{"type":"argon2id","time":18,"memory":1048576,"cpus":4,"salt":"mvXLzWn1IYEOb/a8g0ezfnNTVu9rvwsxC5eMo9e2CiQ="}},"1":{"type":"luks2","key_size":64,"af":{"type":"luks1","stripes":4000,"hash":"sha256"},"area":{"type":"raw","offset":"290816","size":"258048","encryption":"aes-xts-plain64","key_size":64},"kdf":{"type":"argon2id","time":7,"memory":1048576,"cpus":4,"salt":"YTnf/ypEI6y0ssZlRHq3cfRq16175r6aFX2XTUSFN1c="}}},"tokens":{},"segments":{"0":{"type":"crypt","offset":"16777216","size":"dynamic","iv_tweak":"0","encryption":"aes-xts-plain64","sector_size":512}},"digests":{"0":{"type":"pbkdf2","keyslots":["0","1"],"segments":["0"],"hash":"sha512","iterations":173835,"salt":"su+921tALdeckXOJ4W4L2mfZkOKJWUrGwvMjWYFgGlw=","digest":"t4qCg7dnLsHNGhtSCjwxizOxsXFyyJ0fHMxPu9SZAs3XMQU1e7z93Poi1R3UMCUtjD0TjtAARqpHqMw2QEh4+A=="}},"config":{"json_size":"12288","keyslots_size":"16744448"}}
X".e
...random data to the end...

Key Observations:

1. EFI PART: Indicates the EFI GPT (GUID Partition Table) header's presence. This segment was added when Windows mistakenly appended a GPT to the drive.
2. LUKS2 Data: The JSON-style data beginning with {"keyslots": ... corresponds to the LUKS2 header configuration. This data delineates encrypted content unlocking protocols, algorithms employed, key derivation specifics, and more. The LUKS data's lingering presence implies the GPT header didn't completely overwrite the original LUKS2 header. This partial preservation, combined with my backup, facilitated the successful data recovery.

This incident highlights the significance of prudence when working with raw disk tools. Even minimal, unintended alterations can culminate in data access barriers or outright loss. Vigilant backup practices, especially concerning vital headers or metadata, are indispensable.