* [dm-crypt] Size of LUKS header and how to overwrite @ 2016-02-08 22:02 Rypervenche 2016-02-09 1:11 ` Arno Wagner 0 siblings, 1 reply; 13+ messages in thread From: Rypervenche @ 2016-02-08 22:02 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-08 22:02 [dm-crypt] Size of LUKS header and how to overwrite Rypervenche @ 2016-02-09 1:11 ` Arno Wagner 2016-02-09 21:28 ` Rypervenche 0 siblings, 1 reply; 13+ messages in thread From: Arno Wagner @ 2016-02-09 1:11 UTC (permalink / raw) To: dm-crypt 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 -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-09 1:11 ` Arno Wagner @ 2016-02-09 21:28 ` Rypervenche 2016-02-09 23:28 ` Arno Wagner 0 siblings, 1 reply; 13+ messages in thread From: Rypervenche @ 2016-02-09 21:28 UTC (permalink / raw) To: dm-crypt 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@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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-09 21:28 ` Rypervenche @ 2016-02-09 23:28 ` Arno Wagner 2016-02-10 19:13 ` Subscriptions 0 siblings, 1 reply; 13+ messages in thread From: Arno Wagner @ 2016-02-09 23:28 UTC (permalink / raw) To: dm-crypt 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 -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-09 23:28 ` Arno Wagner @ 2016-02-10 19:13 ` Subscriptions 2016-02-10 19:21 ` Arno Wagner 0 siblings, 1 reply; 13+ messages in thread From: Subscriptions @ 2016-02-10 19:13 UTC (permalink / raw) To: dm-crypt 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 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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-10 19:13 ` Subscriptions @ 2016-02-10 19:21 ` Arno Wagner 2016-02-10 19:41 ` Subscriptions 2016-02-10 20:02 ` Michael Kjörling 0 siblings, 2 replies; 13+ messages in thread From: Arno Wagner @ 2016-02-10 19:21 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-10 19:21 ` Arno Wagner @ 2016-02-10 19:41 ` Subscriptions 2016-02-10 20:02 ` Michael Kjörling 1 sibling, 0 replies; 13+ messages in thread From: Subscriptions @ 2016-02-10 19:41 UTC (permalink / raw) To: dm-crypt 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@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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-10 19:21 ` Arno Wagner 2016-02-10 19:41 ` Subscriptions @ 2016-02-10 20:02 ` Michael Kjörling 2016-02-10 20:07 ` Sven Eschenberg 1 sibling, 1 reply; 13+ messages in thread From: Michael Kjörling @ 2016-02-10 20:02 UTC (permalink / raw) To: dm-crypt On 10 Feb 2016 20:21 +0100, from arno@wagner.name (Arno Wagner): > On Wed, Feb 10, 2016 at 20:13:15 CET, Subscriptions wrote: >> 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 Out of curiosity; are you saying that for a given, known, _specific_ LUKS container, the first "payload offset" × 512 bytes is what we need to overwrite if we want to securely erase the entire LUKS header on that container without collateral damage? (Leaving the encrypted data untouched.) Let's ignore here the issue of "overwriting" _anything at all_ on SSDs and SSHDs. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-10 20:02 ` Michael Kjörling @ 2016-02-10 20:07 ` Sven Eschenberg 2016-02-10 20:13 ` Michael Kjörling 0 siblings, 1 reply; 13+ messages in thread From: Sven Eschenberg @ 2016-02-10 20:07 UTC (permalink / raw) To: dm-crypt Yes, it will overwrite the header and potential free space after the header up to the first sector of encrypted data. Does this seem so weird? Regards -Sven Am 10.02.2016 um 21:02 schrieb Michael Kjörling: > On 10 Feb 2016 20:21 +0100, from arno@wagner.name (Arno Wagner): >> On Wed, Feb 10, 2016 at 20:13:15 CET, Subscriptions wrote: >>> 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 > > Out of curiosity; are you saying that for a given, known, _specific_ > LUKS container, the first "payload offset" × 512 bytes is what we need > to overwrite if we want to securely erase the entire LUKS header on > that container without collateral damage? (Leaving the encrypted data > untouched.) > > Let's ignore here the issue of "overwriting" _anything at all_ on SSDs > and SSHDs. > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-10 20:07 ` Sven Eschenberg @ 2016-02-10 20:13 ` Michael Kjörling 2016-02-10 20:29 ` Sven Eschenberg 0 siblings, 1 reply; 13+ messages in thread From: Michael Kjörling @ 2016-02-10 20:13 UTC (permalink / raw) To: dm-crypt On 10 Feb 2016 21:07 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg): > Yes, it will overwrite the header and potential free space after the > header up to the first sector of encrypted data. > > Does this seem so weird? No, but given the somewhat roundabout way this was described in the FAQ at least last I looked, this seems like a much easier way to describe it... -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-10 20:13 ` Michael Kjörling @ 2016-02-10 20:29 ` Sven Eschenberg 2016-02-10 21:50 ` Arno Wagner 0 siblings, 1 reply; 13+ messages in thread From: Sven Eschenberg @ 2016-02-10 20:29 UTC (permalink / raw) To: dm-crypt Ah, I see. Well the FAQ gives alternatives and more information on the size of the header for different keylengths and so on. But as the header+keymaterial can hardly be bigger than the offset of the encrypted payload on the backing device a dd with count=payload-offset and bs=512 indeed does the trick. Of course you'd have to check the payload offset of that particular container and not mix any numbers etc. . Regards -Sven Am 10.02.2016 um 21:13 schrieb Michael Kjörling: > On 10 Feb 2016 21:07 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg): >> Yes, it will overwrite the header and potential free space after the >> header up to the first sector of encrypted data. >> >> Does this seem so weird? > > No, but given the somewhat roundabout way this was described in the > FAQ at least last I looked, this seems like a much easier way to > describe it... > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-10 20:29 ` Sven Eschenberg @ 2016-02-10 21:50 ` Arno Wagner 2016-02-10 22:07 ` Arno Wagner 0 siblings, 1 reply; 13+ messages in thread From: Arno Wagner @ 2016-02-10 21:50 UTC (permalink / raw) To: dm-crypt I should probably update the FAQ with the information about the "payload offset" field in a separate item. Maybe "How to overwrite only the LUKS header". Keep in mind that much of the statements in the FAQ are still in their first incarnation and quite a few things may lack a simplified description, as I like to give the full story. Hence I am grateful if anybody points out such shortcommings. Regards and thanks, Arno On Wed, Feb 10, 2016 at 21:29:07 CET, Sven Eschenberg wrote: > Ah, I see. Well the FAQ gives alternatives and more information on > the size of the header for different keylengths and so on. But as > the header+keymaterial can hardly be bigger than the offset of the > encrypted payload on the backing device a dd with > count=payload-offset and bs=512 indeed does the trick. > > Of course you'd have to check the payload offset of that particular > container and not mix any numbers etc. . > > Regards > > -Sven > > > Am 10.02.2016 um 21:13 schrieb Michael Kjörling: > >On 10 Feb 2016 21:07 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg): > >>Yes, it will overwrite the header and potential free space after the > >>header up to the first sector of encrypted data. > >> > >>Does this seem so weird? > > > >No, but given the somewhat roundabout way this was described in the > >FAQ at least last I looked, this seems like a much easier way to > >describe it... > > > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [dm-crypt] Size of LUKS header and how to overwrite 2016-02-10 21:50 ` Arno Wagner @ 2016-02-10 22:07 ` Arno Wagner 0 siblings, 0 replies; 13+ messages in thread From: Arno Wagner @ 2016-02-10 22:07 UTC (permalink / raw) To: dm-crypt Just added Item 2.20 to the FAQ for this. Regards, Arno On Wed, Feb 10, 2016 at 22:50:14 CET, Arno Wagner wrote: > > I should probably update the FAQ with the information about the > "payload offset" field in a separate item. Maybe "How to overwrite > only the LUKS header". > > Keep in mind that much of the statements in the FAQ are still > in their first incarnation and quite a few things may lack > a simplified description, as I like to give the full story. > Hence I am grateful if anybody points out such shortcommings. > > Regards and thanks, > Arno > > > On Wed, Feb 10, 2016 at 21:29:07 CET, Sven Eschenberg wrote: > > Ah, I see. Well the FAQ gives alternatives and more information on > > the size of the header for different keylengths and so on. But as > > the header+keymaterial can hardly be bigger than the offset of the > > encrypted payload on the backing device a dd with > > count=payload-offset and bs=512 indeed does the trick. > > > > Of course you'd have to check the payload offset of that particular > > container and not mix any numbers etc. . > > > > Regards > > > > -Sven > > > > > > Am 10.02.2016 um 21:13 schrieb Michael Kjörling: > > >On 10 Feb 2016 21:07 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg): > > >>Yes, it will overwrite the header and potential free space after the > > >>header up to the first sector of encrypted data. > > >> > > >>Does this seem so weird? > > > > > >No, but given the somewhat roundabout way this was described in the > > >FAQ at least last I looked, this seems like a much easier way to > > >describe it... > > > > > _______________________________________________ > > 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 > _______________________________________________ > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-02-10 22:07 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-08 22:02 [dm-crypt] Size of LUKS header and how to overwrite Rypervenche 2016-02-09 1:11 ` Arno Wagner 2016-02-09 21:28 ` Rypervenche 2016-02-09 23:28 ` Arno Wagner 2016-02-10 19:13 ` Subscriptions 2016-02-10 19:21 ` Arno Wagner 2016-02-10 19:41 ` Subscriptions 2016-02-10 20:02 ` Michael Kjörling 2016-02-10 20:07 ` Sven Eschenberg 2016-02-10 20:13 ` Michael Kjörling 2016-02-10 20:29 ` Sven Eschenberg 2016-02-10 21:50 ` Arno Wagner 2016-02-10 22:07 ` Arno Wagner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.