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#En...) [1] https://github.com/xmikos/cryptboot -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info