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? 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? 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 beginning of my disk. 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@xxxxxxxxxxx> 已寫入： > 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@xxxxxxxx > > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
