<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 3/26/2013 2:55 PM, Nate Reller
wrote:<br>
</div>
<blockquote
cite="mid:1364334922.23961.YahooMailNeo@web163802.mail.gq1.yahoo.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div style="color:#000; background-color:#fff; font-family:times
new roman, new york, times, serif;font-size:12pt">
<div>I do not think decryption and re-encryption will be
necessary. I will do my<br>
best to describe why via email.<br>
<br>
The image file is used to setup a loop device, which looks
like a normal block<br>
device. The loop device size is limited to the size of the
file backing the<br>
loop device. It maps its idea of sectors to locations in the
file backing the<br>
device. Hence sector 0 will be bytes (0, 511) in the file
backing the device.<br>
Where those bytes are on the physical disk are unknown.<br>
<br>
Normal block device functions are used to read and write data
from a loop <br>
device. Hence in Linux this will be a request call. This will
tell the block<br>
device where to write the data. For example a call could be
made to write data <br>
to the first sector. The first sector is relative to the loop
device and not<br>
the physical device. Therefore data written to the first
sector of the loop <br>
device will be to the first 512 bytes of the file backing the
loop device.<br>
<br>
Now when dm-crypt is used I believe it is setup as another
block device that <br>
sits above the block device to be encrypted. It will simply
encrypt the data <br>
before it is sends the request call down to the lower level
driver. Consider<br>
the example write above again. Now the dm-crypt block device
will receive a<br>
request to write to the first sector. It will encrypt the data
using the sector<br>
number as the IV, and then call the lower block device using
the same <br>
parameters (i.e. send this data to the first sector). The
bytes will then be<br>
written to the first sector of the loop device, which is the
first 512 bytes of<br>
the file backing the device, and who knows where on the
physical device.<br>
<br>
Since the physical sector is not used in the encryption then I
do not see why<br>
the disk would need to be decrypted and then re-encrypted. You
could test this <br>
by creating a file backed loop device, putting dm-crypt on
top, writing data to<br>
it, unmounting it all, copying the file, putting dm-crypt on
top, and reading<br>
the data from it.<br>
<br>
</div>
</div>
</blockquote>
<br>
Just ignore all issues with the local OS. I have an encrypted entity
(volume,<br>
swift partition, object, whatever) on server X that I want to
replicate to<br>
server Y.<br>
<br>
If I replicate the encrypted content, I need to transfer the
decrypting key<br>
to server Y (unless we are working with user-held keys, which is a
wonderful<br>
idea, but would be a totally separate blueprint and project). How do
I do that<br>
safely? This is where I see a key manager as playing a useful role.
It lets<br>
Server X know that it is ok for it transfer key Z to server Y, and
provides<br>
either a Session Key or the Public Key of Server Y to facilitate
this transfer.<br>
<br>
If I don't transfer the key, then I need to transfer the content in
a form where<br>
Server Y can re-encrypt it. That would require decrypting it, and
then encrypting<br>
it for transport so that Server Y could decrypt it from transport
before re-encrypting<br>
it for storage.<br>
<br>
All of that is true no matter what involvement any kernel has in the
whole process.<br>
<br>
These factors also drive your key granularity. If I am only
replicating part of a physical<br>
drive I do not want to transfer the key for the entire drive to the
receiving server.<br>
<br>
</body>
</html>