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 -- 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
