<div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote">Den 28 feb. 2017 14:59 skrev "Darren Moffat" <<a href="mailto:darren@nessieroo.com" target="_blank">darren@nessieroo.com</a>>:<br type="attribution"><blockquote class="m_-4026481012575093401quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="auto"><div><div>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.<br></div><br></div>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.<br></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Tl;dr: It doesn't leak contents, but reveals plaintext repeats (if you can spy on multiple ciphertext writes). </div><div dir="auto"><br></div><div dir="auto">---</div><div dir="auto"><br></div><div dir="auto">As for your use with COW, then if revealing plaintext repeats* isn't a problem, or if your inputs never repeats**, it is safe. </div><div dir="auto"><br></div><div dir="auto">* Repeating in the exact same position. Moving data from one block to another is indistinguishable from two random writes. </div><div dir="auto">Note: this makes it possible to detect behavior like zeroization-write-zeroization. </div><div dir="auto"><br></div><div dir="auto">** Such as a never decreasing counter. </div><div dir="auto"><br></div><div dir="auto">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. <br></div><div dir="auto"><br></div><div dir="auto">---</div><div dir="auto"><br></div><div dir="auto">XTS is deterministic, and encrypts every plaintext block together with randomized inputs that are separately generated for every block. </div><div dir="auto">There's (AFAIK) no support for using a per-session IV, so these per-block inputs are static (but are key dependent). </div><div dir="auto"><br></div><div dir="auto">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). </div><div dir="auto">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). </div><div dir="auto"><br></div><div dir="auto">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... </div><div dir="auto"><br></div><div dir="auto">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). </div><div dir="auto">File headers are also particularly susceptible to end up in the same places with identical contents in some blocks, which would be detectable.  </div><div dir="auto"><br></div><div dir="auto">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). </div><div dir="auto"><br></div><div dir="auto">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.</div><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="m_-4026481012575093401quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="auto"></div></div></blockquote></div></div></div>