<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">Dne 1.3.2017 v 1:17 Natanael napsal(a):<br>
</div>
<blockquote
cite="mid:CAAt2M1-FsON2a=oRViLLF4GB5NjRTK8jEXssS8KLh+n0gVwmzg@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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>
</blockquote>
Better to explain, XTS using two parameters. let's talk about index1
and index2:<br>
- Index1 are index of encryption block inside data block, for
example AES has 16B size, this mean in 512 block index1 can count up
to 32, for 4K block index1 can count up to 256. Index1 can increase
up to 2^20, this mean up to 1048576, this should be a design limit.
Means that one block can grow up to 16MB, but theoretical limit
should be arount 2^128 for 16B block encryption like AES.<br>
- Index2 are data block counter, ie. could be a LBA. But typical LBA
has 22/28/32/64-bit size, this is why I would like take a look how
it is implemented. Teoretical limit are the same, 2^128 for 16B
block encryption like AES.<br>
<br>
Also long key, could be explained as two keys (or first and second
half)<br>
- Key1 / primary key, used for encryption plaintext (blocks inside
the data block), should be the same size as supported by encryption
mechanism, ie 128/192/256b for AES.<br>
- Key2 / secondary key, used for encryption index1, result is
combined with Index2. This create a salt, which is XORed with
plaintext before and after encryption. Key size should be the same
size as supported by encryption mechanism, ie 128/192/256b for AES.<br>
<br>
XTS doesnt support authenticated encryption (AE) or authenticated
encryption with associated data (AEAD), which in result allow
similar attack (like Evil Maid Attack and others). One encrypted
block require 2 encryptions.<br>
<br>
Beside this, since 2009 are standardized EME2 mechanism, which are
almost without limits oposite the XTS. Support ABL, AEAD and require
2,5 encryptions per block, this mean not significantly slower.<br>
<br>
<blockquote
cite="mid:CAAt2M1-FsON2a=oRViLLF4GB5NjRTK8jEXssS8KLh+n0gVwmzg@mail.gmail.com"
type="cite">
<div dir="auto">
<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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
The cryptography mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>
<a class="moz-txt-link-freetext" href="http://www.metzdowd.com/mailman/listinfo/cryptography">http://www.metzdowd.com/mailman/listinfo/cryptography</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Jan Dušátko
Phone: +420 602 427 840
e-mail: <a class="moz-txt-link-abbreviated" href="mailto:jan@dusatko.org">jan@dusatko.org</a>
SkypeID: darmodej
GPG: <a class="moz-txt-link-freetext" href="http://www.dusatko.org/downloads/jdusatko.asc">http://www.dusatko.org/downloads/jdusatko.asc</a>
</pre>
</body>
</html>