From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Wed, 10 Feb 2016 20:13:21 +0100 (CET) Received: from lustre.ryper.org (unknown [IPv6:2001:470:b825:1:3921:cb2a:8d:3ac4]) (Authenticated sender: sub@ryper.org) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 400991720A1 for ; Wed, 10 Feb 2016 20:13:19 +0100 (CET) Date: Wed, 10 Feb 2016 13:13:15 -0600 From: Subscriptions Message-ID: <20160210131315.1991cca7@lustre.ryper.org> In-Reply-To: <20160209232819.GA21086@tansi.org> References: <20160208160227.6a446085@lustre.ryper.org> <20160209011150.GB10406@tansi.org> <20160209152824.774e5d25@lustre.ryper.org> <20160209232819.GA21086@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dm-crypt] Size of LUKS header and how to overwrite List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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=3D/dev/urandom of=3D/dev/sda1 bs=3D512 count=3D8 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 =E5=9C=A8 Wed, 10 Feb 2016 00:28:19 +0100 Arno Wagner =E5=B7=B2=E5=AF=AB=E5=85=A5=EF=BC=9A > Hi, >=20 > 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. > >=20 > > 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? =20 >=20 > That would be 2020 * 512 =3D 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. >=20 > > 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? =20 >=20 > 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. > =20 > > 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 =20 > The unit is not "bit", it is "sectors of 512 bytes". > > the beginning of my disk. =20 >=20 > 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". >=20 > Unless you really understand these, I would strongly recommend > against overwriting anything. Units are critical. If you get=20 > them wrong, you may very well do permanent damage. >=20 > Regards, > Arno >=20 > =20 > > Thank you for your patience with me and thank you for your help, > >=20 > > Rypervenche > >=20 > > =E5=9C=A8 Tue, 9 Feb 2016 02:11:50 +0100 > > Arno Wagner =E5=B7=B2=E5=AF=AB=E5=85=A5=EF=BC=9A > > =20 > > > Hi, > > >=20 > > > FAQ Item 6.12 gives you the sizes and calculations: > > > https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestio= ns > > > Header size depends on several factors. > > > =20 > > > However, you can take the "Payload offset" value and=20 > > > multiply by 512. If you count from zero, that gives you the=20 > > > first byte not to overwrite. > > >=20 > > > You should however know that you cannot reliably delete=20 > > > data from an SSD, see FAQ Item 5.19. > > >=20 > > > Regards, > > > Arno > > >=20 > > >=20 > > > On Mon, Feb 08, 2016 at 23:02:27 CET, Rypervenche wrote: =20 > > > > Hi all, > > > >=20 > > > > 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. > > > >=20 > > > > 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: > > > >=20 > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > # cryptsetup luksDump /dev/sda1 > > > > LUKS header information for /dev/sda1 > > > >=20 > > > > Version: 1 > > > > Cipher name: aes > > > > Cipher mode: xts-plain64 > > > > Hash spec: sha512 > > > > Payload offset: 4096 > > > > MK bits: 512 > > > > ... > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > 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). > > > >=20 > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > # for i in *; do echo $(du -s $i | awk '{print $1}'): $(file $i > > > > | grep -oP '(?<=3D\[).*(?=3D\])'); 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 > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > And lastly, my partition setup: > > > >=20 > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > # gdisk -l /dev/sda > > > > GPT fdisk (gdisk) version 1.0.1 > > > >=20 > > > > Partition table scan: > > > > MBR: protective > > > > BSD: not present > > > > APM: not present > > > > GPT: present > > > >=20 > > > > 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) > > > >=20 > > > > Number Start (sector) End (sector) Size Code Name > > > > 1 2048 500118158 238.5 GiB 8300 Linux > > > > filesystem =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > 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. > > > >=20 > > > > Thank you, > > > >=20 > > > > Rypervenche > > > > _______________________________________________ > > > > dm-crypt mailing list > > > > dm-crypt@saout.de > > > > http://www.saout.de/mailman/listinfo/dm-crypt =20 > > > =20 > >=20 > > _______________________________________________ > > dm-crypt mailing list > > dm-crypt@saout.de > > http://www.saout.de/mailman/listinfo/dm-crypt =20 >=20