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@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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
