[arch-general] Kpartx should be in the repos and archiso for enabling encrypted GPT install

yaro at marupa.net yaro at marupa.net
Mon Jan 14 03:38:34 UTC 2019


On Sun, 2019-01-13 at 22:31 -0500, brent s. wrote:
> On 1/13/19 10:19 PM, brent s. wrote:
> > > Well, unencrypted partition table. What he wants is an encrypted
> > > partition table, and more generally no metadata available (so the
> > > disk
> > > just looks like plain garbage, not x nice labelled partitions
> > > with LUKS
> > > headers).
> 
> also, the LUKS header is still there whether it's on the partition or
> the whole disk. you're in no way obligated to reveal that information
> in
> the GPT's partition type with 7FFEC5C9-2D00-49B7-8941-3EA10A5586B7
> identifier. linux doesn't care what the partition type is labeled as,
> functionally, except to determine auto-raid, unused partitions, and
> LVM
> partitions.
> 
> OP said they're using plain dm-crypt, however, which *doesn't have*
> LUKS
> headers. no matter if it's whole-disk or partition.
> 
> the only way you can get around that is with a luksHeaderBackup to a
> separate source and then a luksHeaderRestore when you want to use it.
> 
> but don't take my word for it.
> 
> https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects
> 
> 
> section 5.2.
> 
> 
> 
> 
> 

No need to use the luksHeaderRestore/luksHeaderBackup. You can create
and use a detached LUKS header with the --header parameter. You can use
--header, combined with a zero offset on the device and no partition
table and it should, in theory, only look like random data across the
entire drive. You could then put LVM on the LUKS container for
"partitioning."

I use a setup like that, though I'm not sure how bootable that setup
could be; especially on UEFI systems which require an unencrypted
system partition.


More information about the arch-general mailing list