I have been using cryptsetup for a while now and just found out about the option 'luksDump'. I am used to similar tools like veracrypt and truecrypt and I am a bit shocked that all these vulnerable data are so easily accessible. If I remember it right, vera- and truecrypt made it impossible to find out cipher and hash with just a small command.
Is there a way to hide these data? Thank You!
It should be noted that this process is what I'd consider overkill for the average person hoping to protect perhaps some private files that wouldn't have life-long effects on their livelihood. The below explanation is more so to elaborate on the answer to the question of what's possible and makes no means to make any claims as to what's realistic.
In fact, it would be the next level of security and steps you would take to secure a system containing highly sensitive or classified information. That is, if you really wanted to go the extra mile and hide it, you can. However, as others have mentioned, it's definitely overkill if it's just some private photos you are worried about, but if you had something more valuable to protect then it is possible to "hide" this by essentially putting it elsewhere.
Physically hiding by keeping it separate Also known as using a Detached Header for your LUKS device, you can remove the header and keep it separate from the system so that without it, there wouldn't seem to be a system to even boot because the separated header can act like a key whereas you would need the header file to supply the information needed by the system to identify the drive as an encrypted drive and provide the means to unlock the partition. Without it, a bad actor would only be able to destroy the data but not access it.
Since we're being cautious, you can take it a step further and also keep the boot partition on the same USB drive so that it also holds the kernel image and initramfs images files with the root partition's LUKS header file (keeping the boot partition and header fil in separate partition. That should address your concern as all that's left is encrypted data.
There are a number of online tutorials on how to accomplish this but an informational overview of the different methodologies and deeper understanding can be found here: https://medium.com/@privb0x23/lose-your-head-attempting-to-boot-from-luks-without-a-header-2d61174df360
And further reference at the man page for cryptsetup regarding the header:
--header <device or file storing the LUKS header> Use a detached (separated) metadata device or file where the LUKS header is stored. This options allows to store ciphertext and LUKS header on different devices.
A simple overview of the process would be something like the following, (depending if you decided to move the boot partition or not, you may find it easier to use a liveboot environment which means you'd have to chroot into the drive to make the updated changes but AFAIK it's not necessary other than for testing) All commands are run as root aside from the first, otherwise just add sudo
To hide the header information, we're going to make a copy of the header and wipe the current one. References to /dev/sda5 should be changed to your system (and could be /dev/nvme0n1p5 for example) while cleanup of items will be left to the individual, such as removing /tmp/usb/ after transferring the header to USB.
Backup the current header:
: mkdir /tmp/usb/
$ cryptsetup luksHeaderBackup /dev/sda5 --header-backup-file /tmp/usb/header.luks
copy it to a USB (alternatively, instead of using the header as a file, you can also use a raw partition that contains the header instead of it being a file inside the partition)
$ cp /tmp/usb/header.luks /dev/media/usb/header.luks
To transition to boot from the copied and newly located header, update system references such as in fstab, crypttab, etc. with new UUID for boot drive and routes (and chroot into the system at this point)
Then edit the entry in fstab with the new UUID
$ nano /etc/fstab
# within the text editor - add a line for your USB device (and another for the /boot partition if you choose to separate that as well)
UUID={device partition UUID} {mount point} {filesystem} {mount options} {dump order}{fsck order}
Alternatively you can just switch the UUID of the current entry for the boot drive and where {mount point} should be /boot and the {dump order}{fsck order} should be 0 1 to update the boot procedure.
Finally, update /etc/crypttab so that it knows to look for the header on the usb being sure to match how it was added in fstab (should be on a separate partition from /boot)
$ crypt_device /dev/sda5 luks,header=/mnt/usb/header.luks
To be sure, test the header backup works (make sure to close it before testing)
$ cryptsetup -v --header /mnt/usb/header.luks open /dev/sda5 decrypted_sda5
If the header is good to go and your Usb is all set, finalize the changes with the initramfs update
$ update-initramfs -u -all
Since you don't want the header information available, then using cryptsetup luksErase /dev/sda4 wouldn't work for you because it only erases the key slots. So to ensure the metadata you're worried about isn't made available, you'll need to completely wipe the header.
You'll need to get the filesystem block size and LUKS data offset
stat -fc %s /dev/sda5 # gives us the block size
cryptsetup luksDump /dev/sd5 # prints the header in human readable form for the offset
then
dd if=/dev/urandom of=/dev/sda5 bs={block size} count={offset}
For a more thorough walkthrough for anyone coming across this answer and may want a deeper understanding of all the commands, try: https://wiki.archlinux.org/title/dm-crypt/Device_encryption
