[dm-crypt] Size of LUKS header and how to overwrite

Subscriptions sub at ryper.org
Wed Feb 10 20:13:15 CET 2016


Thank you very much, Argo, for clearing up these questions for me.

When I said "bit" I was referring to the previously-mentioned bit of
text that I was talking about. It was an ambiguous word to have used on
my part. No confusion between a bit and a byte.

And yes, I was getting confused between a byte and 512-byte sector. I
spent some time with dd and its bs, skip, and count options on my
device to fully understand where the 0 bytes stop and where the
encrypted data begins.

I took a backup of the data that I overwrote and then ran:

dd if=/dev/urandom of=/dev/sda1 bs=512 count=8

All is good and I am now able to boot my system from a detached header,
which I had set up and tested beforehand.

Again, thank you so much for these answers. On my next system I will be
sure to start with a detached header.

Rypervenche

在 Wed, 10 Feb 2016 00:28:19 +0100
Arno Wagner <arno at wagner.name> 已寫入:

> Hi,
> 
> On Tue, Feb 09, 2016 at 22:28:24 CET, Rypervenche wrote:
> > Thank you for your reply, Arno. I had two more questions for the
> > mailing list, if it's not too much trouble.
> > 
> > 1) Why would some of my LUKS header files be 2020 bytes while others
> > are 2048? What would cause this difference? I can see nothing that
> > might cause this to be different save for maybe the number of
> > iterations between the two or a change to the cryptsetup program
> > itself?  
> 
> That would be 2020 * 512 = 103424 bytes, the old 512-byte aligned
> header. Then cryptsetup was changed to align to 1MB borders,
> as that rleminates problems with 4096 byte sectors.
> 
> > 2) As I see that my payload begins at byte 4097, does this mean that
> > bytes 2049 (or 2021?) through 4096 are nothing important and can be
> > overwritten at will?  
> 
> First, that is byte 2097152, i.e. 2MB for the start of data,
> if you start counting at zero. Second, anything before the payload
> start is either header or zeros, and can be overwritten with a
> detached header.
>  
> > I apologize if I somehow missed the information from the FAQs that
> > you posted, I would just like to be 100% clear on this information
> > (and clear up the 2020 vs. 2048 bit) before moving along with
> > overwriting  
> The unit is not "bit", it is "sectors of 512 bytes".
> > the beginning of my disk.  
> 
> You should really be clear between the difference of a "byte"
> and a "512 byte-long sector" before overwriting anything.
> You also should be clear about the difference between "byte"
> (which is 8 bit) and "bit".
> 
> Unless you really understand these, I would strongly recommend
> against overwriting anything. Units are critical. If you get 
> them wrong, you may very well do permanent damage.
> 
> Regards,
> Arno
> 
>  
> > Thank you for your patience with me and thank you for your help,
> > 
> > Rypervenche
> > 
> > 在 Tue, 9 Feb 2016 02:11:50 +0100
> > Arno Wagner <arno at wagner.name> 已寫入:
> >   
> > > Hi,
> > > 
> > > FAQ Item 6.12 gives you the sizes and calculations:
> > > https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
> > > Header size depends on several factors.
> > >  
> > > However, you can take the "Payload offset" value and 
> > > multiply by 512. If you count from zero, that gives you the 
> > > first byte not to overwrite.
> > > 
> > > You should however know that you cannot reliably delete 
> > > data from an SSD, see FAQ Item 5.19.
> > > 
> > > Regards,
> > > Arno
> > > 
> > > 
> > > On Mon, Feb 08, 2016 at 23:02:27 CET, Rypervenche wrote:  
> > > > Hi all,
> > > > 
> > > > I have LUKS on a GPT-partitioned SSD and I have recently been
> > > > looking at moving my LUKS header off of the disk and onto a USB
> > > > drive. I have my initramfs set up to do so, however I am not
> > > > sure how much space to overwrite on my SSD to remove the header
> > > > from it and replace it with random data.
> > > > 
> > > > So, I am not sure how many bytes to remove from the beginning
> > > > of my partition or what to set my --align-payload to. Any help?
> > > > Below is some information that may be useful:
> > > > 
> > > > ==========================================
> > > > # cryptsetup luksDump /dev/sda1
> > > > LUKS header information for /dev/sda1
> > > > 
> > > > Version:       	1
> > > > Cipher name:   	aes
> > > > Cipher mode:   	xts-plain64
> > > > Hash spec:     	sha512
> > > > Payload offset:	4096
> > > > MK bits:       	512
> > > > ...
> > > > ==========================================
> > > > 
> > > > I have heard that the LUKS header should be 2MiB, but I have a
> > > > few headers from previous LUKS-encrypted drives, and I see that
> > > > some are 2020 bytes and others are 2048, I can't see what the
> > > > differences are between them (as you can see one aes,
> > > > xts-plain64, sha512 is 2020 and another is 2048).
> > > > 
> > > > ==========================================
> > > > # for i in *; do echo $(du -s $i | awk '{print $1}'): $(file $i
> > > > | grep -oP '(?<=\[).*(?=\])'); done | sort -n 1028: aes,
> > > > cbc-essiv:sha256, sha1 2020: aes, xts-plain64, sha1
> > > > 2020: aes, xts-plain64, sha1
> > > > 2020: aes, xts-plain64, sha512 (my current SSD that I want to do
> > > > this to) 2048: aes, cbc-essiv:sha256, sha1
> > > > 2048: aes, cbc-essiv:sha256, sha1
> > > > 2048: aes, xts-plain64, sha512
> > > > 2048: aes, xts-plain:sha256, sha1
> > > > ==========================================
> > > > 
> > > > And lastly, my partition setup:
> > > > 
> > > > ==========================================
> > > > # gdisk -l /dev/sda
> > > > GPT fdisk (gdisk) version 1.0.1
> > > > 
> > > > Partition table scan:
> > > >   MBR: protective
> > > >   BSD: not present
> > > >   APM: not present
> > > >   GPT: present
> > > > 
> > > > Found valid GPT with protective MBR; using GPT.
> > > > Disk /dev/sda: 500118192 sectors, 238.5 GiB
> > > > Logical sector size: 512 bytes
> > > > Disk identifier (GUID): 2ACE732B-C8D6-4E03-8E46-1D6A5B4D8CB0
> > > > Partition table holds up to 128 entries
> > > > First usable sector is 34, last usable sector is 500118158
> > > > Partitions will be aligned on 2048-sector boundaries
> > > > Total free space is 2014 sectors (1007.0 KiB)
> > > > 
> > > > Number  Start (sector)    End (sector)  Size       Code  Name
> > > >    1            2048       500118158   238.5 GiB   8300  Linux
> > > > filesystem ==========================================
> > > > 
> > > > I would appreciate it it someone could let me know how I can
> > > > find out exactly how many bytes I should be removing and what I
> > > > should be setting my --align-payload to.
> > > > 
> > > > Thank you,
> > > > 
> > > > Rypervenche
> > > > _______________________________________________
> > > > dm-crypt mailing list
> > > > dm-crypt at saout.de
> > > > http://www.saout.de/mailman/listinfo/dm-crypt    
> > >   
> > 
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt at saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt  
> 



More information about the dm-crypt mailing list