From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (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:41:59 +0100 (CET) Received: from lustre.ryper.org (unknown [IPv6:2001:470:b825:1:3921:cb2a:8d:3ac4]) (Authenticated sender: sub@ryper.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 82CB2A80C8 for ; Wed, 10 Feb 2016 20:41:57 +0100 (CET) Date: Wed, 10 Feb 2016 13:41:35 -0600 From: Subscriptions Message-ID: <20160210134135.2b94aa40@lustre.ryper.org> In-Reply-To: <20160210192121.GA31043@tansi.org> References: <20160208160227.6a446085@lustre.ryper.org> <20160209011150.GB10406@tansi.org> <20160209152824.774e5d25@lustre.ryper.org> <20160209232819.GA21086@tansi.org> <20160210131315.1991cca7@lustre.ryper.org> <20160210192121.GA31043@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 Ohhh, I'll ponder that one for a bit before deciding whether or not to go ahead with it. Thank you. =E5=9C=A8 Wed, 10 Feb 2016 20:21:21 +0100 Arno Wagner =E5=B7=B2=E5=AF=AB=E5=85=A5=EF=BC=9A > On Wed, Feb 10, 2016 at 20:13:15 CET, Subscriptions wrote: > > Thank you very much, Argo, for clearing up these questions for me. > >=20 > > 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. > >=20 > > 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. > >=20 > > I took a backup of the data that I overwrote and then ran: > >=20 > > dd if=3D/dev/urandom of=3D/dev/sda1 bs=3D512 count=3D8 =20 >=20 > That will have killed the header, not the key-slots. As the > header contains an unguessable salt, this is already pretty=20 > secure. >=20 > To also kill the keyslots, run something like >=20 > dd if=3D/dev/urandom of=3D/dev/sda1 bs=3D512 count=3D4096=20 >=20 > if you have "Payload offset: 4096". Or run=20 >=20 > dd if=3D/dev/urandom of=3D/dev/sda1 bs=3D512 count=3D4095 >=20 > just to be careful. This not really any less secure. >=20 > Regards, > Arno >=20 >=20 >=20 > >=20 > > All is good and I am now able to boot my system from a detached > > header, which I had set up and tested beforehand. > >=20 > > Again, thank you so much for these answers. On my next system I > > will be sure to start with a detached header. > >=20 > > Rypervenche > >=20 > > =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 > > =20 > > > Hi, > > >=20 > > > On Tue, Feb 09, 2016 at 22:28:24 CET, Rypervenche wrote: =20 > > > > 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". =20 > > > > 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/FrequentlyAskedQue= stions > > > > > 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 > >=20 > > _______________________________________________ > > dm-crypt mailing list > > dm-crypt@saout.de > > http://www.saout.de/mailman/listinfo/dm-crypt =20 >=20