Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto
Darren J Moffat
Darren.Moffat at Sun.COM
Wed Nov 4 10:04:48 EST 2009
Zooko Wilcox-O'Hearn wrote:
> [Folks, I don't seem to be getting messages from zfs-crypto-discuss so I
> am reading the web archives of zfs-crypto-discuss and replying.]
> Darren Moffat wrote:
> > SHA256 truncated to 192 bits.
> You know, I've thought about this sort of thing quite a lot for
> Tahoe-LAFS and there's a very good reason not to truncate SHA-256 at
> all. That reason is: now you've got to do your own cryptanalysis work.
> Suppose open cryptographers publish better and better attacks on SHA-256
> in the future. As the attacks get better and better, we'll have to
> decide how urgent it is to upgrade from SHA-256 to (hopefully by that
> time) SHA-3. If you're using a truncation of SHA-256 then you might
> need to jump sooner than other people, and you won't know whether or not
> this is the case unless you study the attacks yourself!
That is exactly my concern and why I came here for advice.
I think I'm now convinced that truncating the SHA256 hash would not be a
good idea even though we do have an additional MAC.
> I don't understand the last sentence there. Does this mean that you'll
> never be asked to encrypt more than one plaintext under a different
> birth transaction id? If, so then perfect! -- use the birth transaction
> id as the IV! What other features coming in the future would need to
> know the IV and would not already know the birth transaction id?
In a given birth transaction (txg) there may be many blocks being
encrypted under the same key, so the txg alone isn't enough. The
combination of txg, objset and block id are unique - but that is 192 bits.
One of the possible future features that would need access to the IV is
if we do a version of 'zfs send' (which takes a ZFS filesystem and makes
a stream out of it for replication purposes) that transfers the blocks
as they are on disk (ie compressed and encrypted). Currently the 'zfs
send' works at the DMU layer of ZFS and doesn't deal in transactions or
even disk blocks - it deals in DMU objects and the send stream is all
decrypted and decompressed. To be able to send ciphertext blocks we
will need to send the IV to the remote side too. Which is why we need
to store the IV rather than calculate it - the remote side won't be
putting that ciphertext on disk in the same txg number. I don't want
to do anything now that would make that difficult to do later.
> Something that I still don't understand is: why do you have a MAC tag at
> all if you already have a SHA-256 hash of the ciphertext? David-Sarah
> Hopwood suggested a good reason that you might want one , but is that
> your reason? Because how big the MAC tag needs to be is probably
> determined by why you need it.
The SHA-256 is unkeyed so there would be nothing to stop an attacker
that can write to the disks but doesn't know the key from modifying the
on disk ciphertext and all the SHA-256 hashes up to the top of the
Merkle tree to the uberblock. That would create a valid ZFS pool but
the data would have been tampered with. I don't see that as an
I can't make the SHA-256 keyed because there are ZFS operations that we
must be able to perform with the decryption key is not available:
resilvering a mirror/raidz, disk removal (raid relayout), hotspare,
scrub (proactive resilver).
By using a MAC we reduce that risk because now the attacker needs to
forge the MAC and modify the SHA-256 Merkle tree all the way to the
uberblock as well. Depending on the type of modification the attacker
may actually need to forge multiple MAC tags.
A given MAC tag applies to a single ZFS block that is between 512 bytes
So if I don't truncate the SHA-256 how big does my MAC need to be given
every ZFS block has its own IV ?
Darren J Moffat
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography