[Cryptography] XTS mode IV generation

[Natanael]

Den 28 feb. 2017 14:59 skrev "Darren Moffat" <darren at nessieroo.com>:

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.


Tl;dr: It doesn't leak contents, but reveals plaintext repeats (if you can
spy on multiple ciphertext writes).

---

As for your use with COW, then if revealing plaintext repeats* isn't a
problem, or if your inputs never repeats**, it is safe.

* Repeating in the exact same position. Moving data from one block to
another is indistinguishable from two random writes.
Note: this makes it possible to detect behavior like
zeroization-write-zeroization.

** Such as a never decreasing counter.

Note: this is assuming a passive adversary! An active one can deliberately
reverse block contents to previous versions. This can only be mitigated
with some per-session IV or full-volume MAC or anything similar where the
volume is only valid if fully intact.

---

XTS is deterministic, and encrypts every plaintext block together with
randomized inputs that are separately generated for every block.
There's (AFAIK) no support for using a per-session IV, so these per-block
inputs are static (but are key dependent).

That's a very oversimplified explanation, however, partially because it
needs to be able to support arbitary sized disk blocks (equal to or larger
than the block cipher's block size).
The way it is implemented also limits the maximum size of the encrypted
volume (haven't looked up why) to some multiple of the number of cipher
blocks. For AES with its 128 bit blocks, that's about 4TB (IIRC).

As a result of its design, XTS doesn't reveal if a plaintext block repeats
*within* a volume (meaning that all zeroes is not distinguishable from
random), but...

It DOES reveal to somebody who has *multiple snapshots of the same
encrypted volume* which blocks has changed or not between snapshots, AND it
reveals if they have changed back to a previous plaintext value (such as
repeatedly writing data, and then frequently zeroing out unused blocks).
File headers are also particularly susceptible to end up in the same places
with identical contents in some blocks, which would be detectable.

Without something like a per-session IV and with deterministic encryption
algorithms, this is unavoidable. Rekeying is a possible mitigation, but
requires either full re-encryption (expensive) or tracking multiple keys
(complicated, adds storage overhead).

XTS works great against the harddrive loss / theft threat model. Perhaps
even for your own servers. But it works less great for outsourced cloud
storage, in case you care about metadata secrecy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170301/04bfb812/attachment.html>