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

Subscriptions sub at ryper.org
Wed Feb 10 20:41:35 CET 2016


Ohhh, I'll ponder that one for a bit before deciding whether or not to
go ahead with it. Thank you.

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

> On Wed, Feb 10, 2016 at 20:13:15 CET, Subscriptions wrote:
> > 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  
> 
> That will have killed the header, not the key-slots. As the
> header contains an unguessable salt, this is already pretty 
> secure.
> 
> To also kill the keyslots, run something like
> 
>    dd if=/dev/urandom of=/dev/sda1 bs=512 count=4096 
> 
> if you have "Payload offset:       4096". Or run 
> 
>   dd if=/dev/urandom of=/dev/sda1 bs=512 count=4095
> 
> just to be careful. This not really any less secure.
> 
> Regards,
> Arno
> 
> 
> 
> > 
> > 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    
> > >   
> > 
> > _______________________________________________
> > 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