> >> If you do need hibernation support, the simple method would be to use a > >> swap file residing on the encrypted / > > > > Simple as in "already well supported", but not optimal, as swap > > depends on a filesystem. > > Linux also depends on a filesystem. I'm not sure what you mean to imply. I just prefer a swap partition to a swap file. > >> 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. No, it is not Full Disk Encryption if the disk is not fully encrypted. Also, I think you misunderstood something about that example of FDE with LVM, as in that case the LVM header is, in fact, encrypted (along with the rest of the disk), and a hypothetical attacker can not read it. What do you mean by "proprietary hardware-encrypted solution"? > >> None of this needs kpartx.> > > Thank you for input, indeed all your suggestions would work, but I am > > going for the optimal solution here, and kpartx (or an equivalent > > devmapper program) seems to be a requirement for that. > > The optimal solution according to what metric? If you really want > kpartx, nothing stops you from going right ... ... ... Yes, but I am sure you can see it would be preferable to have the kpartx executable on the iso, as less work is better. Regards, Neven Sajko
