[Cryptography] XTS mode IV generation

Ray Dillinger bear at sonic.net
Tue Feb 28 17:52:21 EST 2017



On 02/28/2017 04:38 AM, Darren Moffat wrote:
> I'm looking for information on wither it is safe (not ideal) to use XTS
> mode in a Copy On Write filesystem. For ZFS (which is copy on write and
> always has a merkle tree of checksums)I used CCM or GCM because there was
> space to store the IV and the MAC.
> 
> I have a use case where the system is still copy on write but there is no
> possibility of storing the IV or a MAC.  In some (but not all) cases the
> ciphertext of the blocks are still checksumed.
> 
> The blocks are not the traditional disk blocks of full disk encryption that
> XTS is target for. Each block that would be encrypted by XTS is  referenced
> by an 128 bit id.  What this means is that due to copy on write the same
> 128 bit id will be used again (always representing the same object and
> fragment of the object) while the prior block is still lying on the storage
> media.  If this 128 bit id was used as the IV for XTS is that weakening the
> security of XTS ? Or is it really no different to the risk of being able to
> observe the same disk locations over time when XTS is used in the
> traditional full disk encryption case?

It is really no different from the risk of being able to observe the
same disk locations over time when XTS is used in the traditional full
disk encryption case.  Early disk encryption systems used CTR, which
failed catastrophically if an attacker ever saw two different
ciphertexts at the same location.  XTS and related systems mitigate that
difficulty by properly encrypting the data rather than just masking it
with an encrypted counter.

However, that is not at all the same as saying the ability to observe
the same disk locations over time does not weaken the system.

XTS is still subject to replay attacks; someone can revert your changes
at chosen locations by replacing blocks on your disk with old values.
In a copy-on-write system, they don't have to change the (encrypted)
block pointers to point at the old block; they have to break the
copy-on-write logic by putting the old block image in place at the
block's current location (where the block pointers they can't get at are
pointing).

This is why ZFS keeps a Merkle tree of checksums. The only way for
a Merkle-tree checked filesystem to be reverted is for every last
sector to be reverted. There is no reversion at selected locations.

				Bear


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170228/381f8462/attachment.sig>


More information about the cryptography mailing list