Does the content of LUKS disks become encrypted again at unmount or at power-off

The data on disk in a LUKS volume using encryption is always stored encrypted; there is never a time when the data is stored in decrypted form on-disk. Decryption happens on the fly as data is read from the volume, and encryption happens on the fly as data is written to the volume.

This ensures that data is safe on disk even if the disk is extracted while the system is running.

The contents of the disk are always encrypted.

When you supply LUKS with the encryption key what happens is that when the OS tries to read from the mounted volume the LUKS driver will read the encrypted data, unencrypt it in memory, then provide the results to the OS. Similarly when the OS tries to write to the disk the LUKS driver will encrypt the data and write that to the disk.

So at all times the data on disk is encrypted.

So what we need to concern ourselves with is the persistence of the key in memory.

Because the LUKS encryption is done at a lower layer than, typically a umount won't remove the key.

So, for example if you do

# cryptsetup luksOpen /dev/xvdc mydisk # mount /dev/mapper/mydisk /mnt ... do stuff # umount /mnt 

Now the luks volume is still open and the key is still in memory. So you can do the mount command again.

For example:

# cryptsetup luksOpen testfile test Enter passphrase for testfile: # mount /dev/mapper/test /mnt # touch /mnt/afile # ls /mnt afile lost+found/ # umount /mnt # mount /dev/mapper/test /mnt # ls /mnt afile lost+found/ # umount /mnt 

However if you do a luksClose then the key is removed and you have to do a luksOpen again and resupply they key.

# cryptsetup luksClose test # mount /dev/mapper/test /mnt mount: /mnt: fsconfig() failed: /dev/mapper/test: Can't lookup blockdev. dmesg(1) may have more information after failed mount system call. # cryptsetup luksOpen testfile test Enter passphrase for testfile: 

A reboot is not needed, just a luksClose.

The contents of the disk is always encrypted. Data from the disk is decrypted only when read from the mapped LUKS device -- if you look at the devices on your system, you'll see a new crypt device (by default named luks-<UUID>) "on top" of your encrypted device:

└─nvme0n1p3 259:3 0 892,7G 0 part └─luks-dfcda59b-1322-4705-bb04-e09a72b2d678 252:0 0 892,7G 0 crypt 

when data is read from this device, system reads the encrypted data from the underlying partition and decrypts it before returning.

When the system is running, to fully disable the access to the data, unmounting is not enough, you need to close the LUKS mapping using cryptsetup close <device>. This happens automatically during shutdown. If you select the eject option in your GUI file manager it also first closes the mapping.

The data on the disk remains encrypted. Have a look at the first paragraph of this Fedora guide to LUKS encryption:

Block device encryption encrypts/decrypts the data transparently as it is written/read from block devices, the underlying block device sees only encrypted data.

The "underlying block device" is what your question and this answer call "the disk".

Re-phrasing the statement in the guide: the data on the disks stay encrypted. Decryption happens when the Linux kernel reads a block of data from the disk into a buffer area in RAM, and the decrypted contents are passed to the running program which asked for the contents. Writes happen the other way around - a running program makes a write() call with a buffer of contents it wants to put on the disk, and the Linux kernel encrypts the contents of the buffer and writes the encrypted data onto the disk.

The transformation from encrypted data to decrypted data (and vice versa) happens in RAM, mediated by the Linux kernel.