Neil A. Wilson wrote:
Darren J Moffat wrote:
While encryption of existing data is not in scope for the first ZFS
crypto phase I am being careful in the design to ensure that it can be
done later if such a ZFS "framework" becomes available.
The biggest problem I see with this is one of observability, if not
all of the data is encrypted yet what should the encryption property
say ? If it says encryption is on then the admin might think the data
is "safe", but if it says it is off that isn't the truth either
because some of it maybe in encrypted.
I would also think that there's a significant problem around what to do
about the previously unencrypted data. I assume that when performing a
"scrub" to encrypt the data, the encrypted data will not be written on
the same blocks previously used to hold the unencrypted data. As such,
there's a very good chance that the unencrypted data would still be
there for quite some time. You may not be able to access it through the
filesystem, but someone with access to the raw disks may be able to
recover at least parts of it. In this case, the "scrub" would not only
have to write the encrypted data but also overwrite the unencrypted data
(multiple times?).
Right, that is a very important issue. Would a ZFS "scrub" framework do
copy on write ? As you point out if it doesn't then we still need to do
something about the old clear text blocks because strings(1) over the
raw disk will show them.
I see the desire to have a knob that says "make this encrypted now" but
I personally believe that it is actually better if you can make this
choice at the time you create the ZFS data set.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
