Truncating SHA2 hashes vs shortening a MAC for ZFS Crypto

[Darren J Moffat]

David-Sarah Hopwood wrote:
> Of course we also need to consider the space constraints. 384 bits
> would fit two 192-bit hashes for the plaintext and ciphertext
> verifiers; but then we would have no space to accomodate the
> ciphertext expansion that results from encrypting the salt together
> with the plaintext.

Which is is where I was originally, the IV wasn't stored because there 
was a way to derive a secure (for CCM/GCM use) IV from other things in 
the block pointer.

> I'm not familiar enough with ZFS's on-disk format to tell whether there
> is a way around this. Note that the encrypted salt does not need to
> be stored in the same place as either the verifiers or the rest of
> the ciphertext.

The IV needs to be stored in ZFS because of some future ZFS features 
where I can't use a derived IV (the first of which will be the project 
that brings device eviction, this involves "moving" encrypted blocks to 
a new place and must work without the keys present).

>> A MAC on the plaintext tells you only that the plaintext was
>> chosen by someone who knew the key.  See what I mean?  A MAC can't be
>> used to give someone the ability to read some data while withholding
>> from them the ability to alter that data.  A secure hash can.
> 
> Right. If hashes are used instead of MACs, then the integrity of the
> system does not depend on keeping secrets. It only depends on preventing
> the attacker from modifying the root of the Merkle tree. One consequence
> of this is that if there are side-channel attacks against the
> implementations of crypto algorithms, there is no information that they
> can leak to an attacker that would allow compromising integrity.

Right.  The reason for using the CCM/GCM AuthTag (MAC) was well as a 
SHA256 hash of the ciphertext is to provide some protection against an 
attack where the root of the Merkele tree is modified in such away that 
the SHA256 hashes all match.

> (Of course, the integrity of the OS also needs to be protected. One way
> of doing that would be to have a TPM, or the same hardware that is used
> for crypto, store the root hash of the Merkle tree and also the hash
> of a boot loader that supports ZFS. Then the boot loader would load an
> OS from the ZFS filesystem, and only that OS would be permitted to update
> the ZFS root hash.)

That is my plan longer term, it will come partly from the ZFS crypto 
project and partly from another OpenSolaris project called Validated 
Execution.

>> One of the founding ideas of the whole design of ZFS was end-to-end
>> integrity checking.  It does that successfully now, for the case of
>> accidents, using large checksums.  If the checksum is secure then it
>> also does it for the case of malice.  In contrast a MAC doesn't do
>> "end-to-end" integrity checking.
> 
> A cryptographic checksum on the ciphertext alone doesn't do end-to-end
> integrity checking either. Even if everything is implemented correctly
> and there are no hardware errors, it doesn't verify the integrity of the
> decryption key.

Right and verifying the decryption key does happen with enough 
confidence with the CCM/GCM AuthTag.  We don't want ZFS to return 
"garbage" if given a wrong decryption key we want it to fail and tell 
the user (via the normal UNIX errno system for system calls).

>> Likewise, a secure hash can be relied on as a dedupe tag *even* if
>> someone with malicious intent may have slipped data into the pool.  An
>> insecure hash or a MAC tag can't -- a malicious actor could submit data
>> which would cause a collision in an insecure hash or a MAC tag, causing
>> tag-based dedupe to mistakenly unify two different blocks.
> 
> I agree. I don't think that Darren Moffat was suggesting to use the MAC tag
> for dedupe. I also agree that a hash used for dedupe needs to be quite long
> (256 bits would be nice, but 192 is probably OK).

Correct, I wasn't suggesting using the MAC for dedup.

I'm going to have both a SHA256 hash of the ciphertext and the CCM/GCM 
AuthTag and I need to store the IV because of other ZFS features.

The main reason for asking here for advice was on the issue of how big 
should the CCM/GCM AuthTag be versus the size of the SHA256 hash of the 
ciphertext, given I have to make a trade off.

--
Darren J Moffat

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