Open Stack

On 3/26/2013 2:55 PM, Nate Reller wrote:
> I do not think decryption and re-encryption will be necessary. I will 
> do my
> best to describe why via email.
>
> The image file is used to setup a loop device, which looks like a 
> normal block
> device. The loop device size is limited to the size of the file 
> backing the
> loop device. It maps its idea of sectors to locations in the file 
> backing the
> device. Hence sector 0 will be bytes (0, 511) in the file backing the 
> device.
> Where those bytes are on the physical disk are unknown.
>
> Normal block device functions are used to read and write data from a loop
> device.  Hence in Linux this will be a request call. This will tell 
> the block
> device where to write the data. For example a call could be made to 
> write data
> to the first sector. The first sector is relative to the loop device 
> and not
> the physical device.  Therefore data written to the first sector of 
> the loop
> device will be to the first 512 bytes of the file backing the loop device.
>
> Now when dm-crypt is used I believe it is setup as another block 
> device that
> sits above the block device to be encrypted. It will simply encrypt 
> the data
> before it is sends the request call down to the lower level driver. 
> Consider
> the example write above again. Now the dm-crypt block device will 
> receive a
> request to write to the first sector. It will encrypt the data using 
> the sector
> number as the IV, and then call the lower block device using the same
> parameters (i.e. send this data to the first sector). The bytes will 
> then be
> written to the first sector of the loop device, which is the first 512 
> bytes of
> the file backing the device, and who knows where on the physical device.
>
> Since the physical sector is not used in the encryption then I do not 
> see why
> the disk would need to be decrypted and then re-encrypted. You could 
> test this
> by creating a file backed loop device, putting dm-crypt on top, 
> writing data to
> it, unmounting it all, copying the file, putting dm-crypt on top, and 
> reading
> the data from it.
>

Just ignore all issues with the local OS. I have an encrypted entity 
(volume,
swift partition, object, whatever) on server X that I want to replicate to
server Y.

If I replicate the encrypted content, I need to transfer the decrypting key
to server Y (unless we are working with user-held keys, which is a wonderful
idea, but would be a totally separate blueprint and project). How do I 
do that
safely? This is where I see a key manager as playing a useful role. It lets
Server X know that it is ok for it transfer key Z to server Y, and provides
either a Session Key or the Public Key of Server Y to facilitate this 
transfer.

If I don't transfer the key, then I need to transfer the content in a 
form where
Server Y can re-encrypt it. That would require decrypting it, and then 
encrypting
it for transport so that Server Y could decrypt it from transport before 
re-encrypting
it for storage.

All of that is true no matter what involvement any kernel has in the 
whole process.

These factors also drive your key granularity. If I am only replicating 
part of a physical
drive I do not want to transfer the key for the entire drive to the 
receiving server.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130326/e022fe7a/attachment.html>