LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Implications of a compressible LUKS1 header? (https://www.linuxquestions.org/questions/linux-security-4/implications-of-a-compressible-luks1-header-4175679941/)

tjallen 08-05-2020 09:05 AM

Implications of a compressible LUKS1 header?
 
I have two external backup drives encrypted with LUKS and I have backed up their LUKS headers. Both drives are encrypted with the same ciphers, hash functions, and have the same passphrases. I noticed that the headers are the same size, but when I gzip them, one is uncompressible and stays at about 2 MiB in size, while the other compresses down to about an eighth of the size: 254 KiB. I first noticed that something was odd because I had used gpg to encrypt the headers and found the same result with the .gpg files. All the LUKS headers for my other disks are essentially incompressible.

My question is whether there's a problem with the LUKS encryption of my drive with the compressible header. Perhaps the encryption key is weak? Should I re-encrypt the drive with the compressible header?

Does anyone have an idea of what's up with the compressible LUKS header?

berndbausch 08-05-2020 09:19 AM

You can use cryptsetup luksdump to look into header contents and compare.

"Compressible" means that there are long strings of identical bytes or byte patterns, often zeros. Perhaps one disk was wiped with zeros before creating the header, and the other wasn't and still contains hard to compress garbage. Programs like hexdump or od might help confirming this.

tjallen 08-05-2020 10:09 AM

berndbausch,

Thanks for the reply. cryptsetup luksDump doesn't seem particularly different for the two drives. I did start to fill the first drive with random data but at the rate it was going I saw that it would have taken more than a week to do so, so I stopped after I figured that out and I didn't bother with the second drive, preferring instead to fill the encrypted filesystems with zeros after encryption instead, which should accomplish the same thing. If the header contains some data from the drive before encryption when not all key slots are filled, that would explain it. I thought of opening copies of the headers in a hex editor, but I'm not sure what I'd be looking at, so I haven't done it.

Ted

tjallen 08-05-2020 12:48 PM

berndbausch,

Surely you are correct that the file is small because I didn't write random data to the drive first. I opened the header files in a hex editor and after the first 254 KiB or so, the file is all zeroes. Thanks for the answer!

Ted


All times are GMT -5. The time now is 03:32 AM.