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

[Arno Wagner <arno@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@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@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@saout.de
> > > > > http://www.saout.de/mailman/listinfo/dm-crypt    
> > > >   
> > > 
> > > _______________________________________________
> > > dm-crypt mailing list
> > > dm-crypt@saout.de
> > > http://www.saout.de/mailman/listinfo/dm-crypt  
> > 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier