zfs crypto discuss - Aug 2007 - Indistinguishability of data blocks

It would be interesting if ZFS was able to natively provide
indistinguishability between the empty (not-yet-used) data blocks and the
written (already-used) data blocks. This would support notions such as
plausible deniability for the presence or not of information on disk: in
case someone does not want to disclose the presence of written information
on the disk, he just needs to forget the password/key, and there''s no
way
for someone else to prove that indeed there was something on disk.

An implementation of such indistinguishability would require ZFS to
prepare/format every partition''s (pools''?) underlying blocks
with random
data, and only write on them encrypted data without any verifiable plaintext
in any form (no plaintexts such as meta-tags, backup info, asn.1 encoding
for pkcs#, etc). As a result, every data block would always contain random
data.

This behavior should be made the default one for ZFS (so that using it does
not suggest any reason for hiding something), but a parameter while making
the partition/pool might be added for not filling it with random data, for
performance reasons on specific situations.

Any thoughts on that?

[]s,
M.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-crypto-discuss/attachments/20070802/71ef1b91/attachment.html>

Mrc Gran wrote:
> 
> It would be interesting if ZFS was able to natively provide 
> indistinguishability between the empty (not-yet-used) data blocks and 
> the written (already-used) data blocks. This would support notions such 
> as plausible deniability for the presence or not of information on disk: 
> in case someone does not want to disclose the presence of written 
> information on the disk, he just needs to forget the password/key, and 
> there''s no way for someone else to prove that indeed there was
something
> on disk.
This is not a goal of the ZFS crypto project.

If you want this type of crypto protection for disk storage it is best 
to do the crypto below the filesystem. For example inside the disk 
driver or in the HBA itself.  Or alternatively use something like what 
the opensolaris.org loficc project does - it acts a "shim" above the 
device and below the filesystem.
> An implementation of such indistinguishability would require ZFS to 
> prepare/format every partition''s (pools''?) underlying
blocks with random
> data, and only write on them encrypted data without any verifiable 
> plaintext in any form (no plaintexts such as meta-tags, backup info, 
> asn.1 encoding for pkcs#, etc). As a result, every data block would 
> always contain random data.
You make it sound very simple, however it is far from being that simple.
> This behavior should be made the default one for ZFS (so that using it 
> does not suggest any reason for hiding something), but a parameter while 
> making the partition/pool might be added for not filling it with random 
> data, for performance reasons on specific situations.
> 
> Any thoughts on that?
It just doesn''t fit with the other goals of the ZFS crypto project as I
have defined it.  The goals of the project phases I identified came from 
customer requirements and not a single customer that was asked requested 
plausible dependability as a feature (which is one term often used for 
what you describe).

Feel free however to attempt to add this to ZFS yourself though, that is 
the beauty of open source.

--
Darren J Moffat