Warning! New cryptographic modes!

[Darren J Moffat]

Jerry Leichter wrote:
> To support insertions or deletions of full blocks, you can't make the 
> block encryption depend on the block position in the file, since that's 
> subject to change.  For a disk encryptor that can't add data to the 
> file, that's a killer; for an rsync pre-processor, it's no big deal - 
> just store the necessary key-generation or tweak data with each block.  
> This has no effect on security - the position data was public anyway.

That is basically what I'm doing in adding encryption to ZFS[1].  Each 
ZFS block in an encrypted dataset is encrypted with a separate IV and 
has its own AES-CCM MAC both of which are stored in the block pointer 
(the whole encrypted block is then checksumed with an unkeyed SHA256 
which forms a merkle tree).

> To handle smaller inserts or deletes, you need to ensure that the 
> underlying blocks "get back into sync".  The gzip technique I mentioned 
> earlier works.  Keep a running cryptographically secure checksum over 
> the last blocksize bytes.  

ZFS already supports gzip compression but only does so on ZFS blocks not 
on files so it doesn't need to do this trick.  The downside is we don't 
get as good a compression as when you can look at the whole file.

ZFS has its own replication system in its send/recv commands (which take 
a ZFS dataset and produce either a full or delta between snapshots 
object change list).  My plan for this is to be able to send the per 
block changes as ciphertext so that we don't have to decrypt and 
re-encrypt the data.  Note this doesn't help rsync though since the 
stream format is specific to ZFS.

[1] http://opensolaris.org/os/project/zfs-crypto/

--
Darren J Moffat

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com