I understood something different by "while disk encryption".  I thought it meant
encrypting the whole disk (partition table and all) not just the partitions on it.

J'

On Wed, Oct 05, 2016 at 07:56:23PM -0700, dian_cecht@zoho.com wrote:
     Hello,
     
          So apparently I've accidentilly volunteered to try and implement whole disk
     encryption for GuixSD, and for the last few days I've been pondering what all
     I'd need to handle for this. While the obvious low-hanging fruit is to simply
     support mounting LUKS devices (or anything under /dev/mapper), if I'm going
     to do this I'd rather try to handle as many cases as I could, or at least avoid
     doing something that would make future additions to the distro painful to
     implement. So I've been trying to come up with a list of the possible
     configurations and how they can be implemented, so at least I have a rough idea
     on what is actually needed. So far, this is what I'm thinking needs to be
     supported (or some combination of each of these):
     
     a) Encrypting /home(/$USER)
     b) Encrypting /
     c) Encrypting /boot
     d) Encrypting swap with a fixed passphrase
     e) Encrypting swap with a random passphrase
     f) Encrypting /$RANDOM_DIRECTORY
     
          I think A is usually handled with eCryptFS and PAM so that the user's home
     directory isn't mounted until the user logs in, and is thus outside of the scope
     of what I'm trying to do. B is the big issue for me (along with RAID support and
     LVM, but I'm reasonably sure I can replace LVM with quotas without any loss of
     functionality and probably an increase in flexibility) and can usually be
     handled fairly easily with an initramfs. However, the inability of the install
     image to mount (or configure these devices for mounting) seems to be a fairly
     serious stumbling block. C is supported by GRUB2 according to 
     https://wiki.archlinux.org/index.php/Grub#Boot_partition
     so as long as our version of GRUB has built-in support for this, I think that
     shouldn't be too hard to handle. D should be reasonably easy to handle as soon
     as we can decide whether it would be better to decrypt everything in the
     initramfs or leave some of it to the system proper to handle. E is likely best
     handled by the system proper and should be reasonably easy to handle once
     a framework for handling decrypting and encrypting filesystems is implemented.
     The same applies to F, for that matter.
     
          I am also pondering how to handle RAID and LVM at this time since all of
     this is all fairly closely related, though I'm not going to make any claims of
     responsibility for implementing anything other than disk encryption, and even
     that isn't promised.
     
          However, I'm wanting feedback from others on this list (and if someone
     wants to crosspost this to the help-guix list for a little more visability, feel
     free) on any possible scenerios need to be handled that I havn't mentioned here.
     

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.