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.
