Encrypted slice with geli

[Giorgos Keramidas]

On Wed, 22 Apr 2009 02:42:11 +0200, Bernt Hansson <bernt at bah.homeip.net> wrote:
>Bill Moran said the following on 2009-04-21 14:41:
>>In response to Bernt Hansson <bernt at bah.homeip.net>:
>>>Giorgos Keramidas said the following on 2009-04-20 23:59:
>>>>On Mon, 20 Apr 2009 21:38:54 +0200, Bernt Hansson <bernt at bah.homeip.net> wrote:
>>>>> Hello list!
>>>>>
>>>>> I was thinking of makeing a slice encrypted with geli.
>>>>>
>>>>> My question is: does geli init -s 4096 /dev/ad* erase the data on the
>>>>> slice. The handbook didn't say yes or no, and I don't want to try
>>>>> without asking.
>>>> No,
>>>
>>> No, what? does it erase the data or not.
>>
>> It depends on exactly what part of the process you're talking about
>
> My question is: does geli init -s 4096 /dev/ad* erase the data on the
> slice.

No, but it *does* write in parts of the slice.  In particular, it writes
geli metadata to the last sector of the device.  If this sector happens
to be "in use" by the existing data on the device, you will lose the
data of this particular sector.

The rest of the actual data stored on the rest underlying device is not
affected by the "geli init" command.

>> and it depends on exactly what you mean by "erase".
>
> Destroy it so it's no longer aviable.

No, the actual data will *still* be on the raw device after you run the
initial "geli init" command.  Even _after_ you newfs the new encrypted
device, block allocation algorithms for the filesystem may selectively
write in some parts of the unencrypted device but skip others.  This
means that until you explicitly fill the encrypted device to its full
capacity, it may _still_ be possible to peek under geli and see some of
the previously stored data.  This is precisely why the geli manpage
suggests that you overwrite the full encrypted device with data from
`/dev/random'.

>> If your question is, "I'm switching a partition to using geli, do I
>> need to back up my data before doing so?" the answer is YES!
>
> I do NOT want to backup the data unencrypted.
>
>>> But I want to keep the info on the slice.
>>
>> Then you need to copy it elsewhere, then copy it back after the slice
>> is encrypted.
>
> Dont have the space for that.

If you find the space for a full backup, then you can backup the data in
*encrypted* form too, i.e. by saving two geli keys in a removable device
(a USB flash disk maybe) and then going through two geli devices:

    0.  save two geli keys on a removable device, i.e. key-a and key-b

    1.  geli init the backup device with key-a and geli attach it

    2.  overwrite the backup device with /dev/random data

    3.  newfs and mount the backup device

    4.  dump everything from the original unencrypted device to the
        newly encrypted backup device

    5.  geli init the original device with key-b and attach it

    6.  overwrite the new encrypted device with /dev/random data

    7.  newfs and mount the newly encrypted device

    8.  restore from the encrypted backup device to the new encrypted
        device

    9.  verify that everything works in the newly encrypted device

    10. detach the encrypted backup device and overwrite it with
        /dev/random data once more

All you need is a backup device that is large enough to hold a full
backup of your data and a moderately safe place to store the encryption
keys while you are doing the whole backup and restore dance.