[dm-crypt] Size of LUKS header and how to overwrite

[dm-crypt] Size of LUKS header and how to overwrite

[Rypervenche]

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

Re: [dm-crypt] Size of LUKS header and how to overwrite

[Arno Wagner]

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

Re: [dm-crypt] Size of LUKS header and how to overwrite

[Rypervenche]

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  
> 

Re: [dm-crypt] Size of LUKS header and how to overwrite

[Arno Wagner]

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

Re: [dm-crypt] Size of LUKS header and how to overwrite

[Subscriptions]

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  
> 

Re: [dm-crypt] Size of LUKS header and how to overwrite

[Arno Wagner]

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

Re: [dm-crypt] Size of LUKS header and how to overwrite

[Subscriptions]

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  
> 

Re: [dm-crypt] Size of LUKS header and how to overwrite

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

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

Re: [dm-crypt] Size of LUKS header and how to overwrite

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

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

Re: [dm-crypt] Size of LUKS header and how to overwrite

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

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

Re: [dm-crypt] Size of LUKS header and how to overwrite

[Sven Eschenberg]

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

Re: [dm-crypt] Size of LUKS header and how to overwrite

[Arno Wagner]

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

Re: [dm-crypt] Size of LUKS header and how to overwrite

[Arno Wagner]

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