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@xxxxxxxxxxx> 已寫入： > 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@xxxxxxxxxxx> 已寫入： > > > > > 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 > > > > > > > _______________________________________________ > > 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
