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

[brent s.]

On 1/13/19 5:43 PM, Bruno Pagani via arch-general wrote:
> Le 13/01/2019 à 23:27, Eli Schwartz via arch-general a écrit :
>> The more complex method would be to copy the initramfs encrypt hook and
>>>> modify it to support an additional encrypted device with a different
>>>> password.
>>> I want full disk encryption. There is nothing controversial about FDE,
>>> it is already covered in the Wiki, except that I want FDE without LVM.
>> You can have FDE without LVM today, using the suggestion I just provided
>> and you ignored.
>>
>> Unless you mean that it's not really FDE if attackers can read the
>> partition table layout, in which case LVM is not valid as FDE and you'd
>> better buy yourself some proprietary hardware-encrypted solution.
> 
> Readable partition table layout is exactly the issue (and you answered
> yourself about your LVM mistake).
> 

plausible deniability only works if it doesn't look like you're hiding
something.

given the mention of wanting to encrypt /, i'm assuming this is intended
to be a live OS.

that means you still need unencrypted boot code in *some* form, even if
you use [0] or [1]. sure, you can keep your boot code on a separate USB
dongle or what have you, but for UEFI that entry is still going to be in
there (unless you're booting to an EFI shell and manually booting every
time).

hence my "increasing headache tenfold" comment earlier.

>> But I still do not understand what practical benefits you are seeking
>> that are not solved by having multiple encrypted partitions on an
>> unencrypted partition table.
> 
> 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).

see above.

FDE, even "full" FDE, is not a magic bullet. if your threat model is so
serious that you're worried about people *knowing* you have an encrypted
disk, OpSec is going to save you more than encryption. otherwise, FDE's
just one *part* of a robust security protocol. generally speaking, when
your threat model is that of the above, it's *far* better to:

- have a "normal-looking" OS installed on the computer with some (fake)
photos of "family", some fake documents here and there, some fake
browsing history, etc. on...
- an unencrypted system partition
- and use a separate easily physically hidden (encrypted) actual OS on a
thumbdrive
- with *access* to a remote resource that has your real data, not the
real data on the thumbdrive itself

and then throw that entire kit away after whatever operation you've done
is complete and you're back in a safe zone and never use it again.

that's a lot less suspicious (and a lot less likely to attract attention
to yourself - the very LAST thing you want if you truly believe and are
a valuable target) than walking around with a device that's obviously
being used yet has a disk full of what looks like random data.

however, if you're just trying to prevent against joe blow getting your
ssh keys in case your laptop gets stolen or lost, encrypting the
partition table gains you nothing except unnecessary work. ROI.


[0]
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_(GRUB)
[1] https://github.com/xmikos/cryptboot

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20190113/a9a20985/attachment-0001.asc>