[Cryptography] XTS mode IV generation

[Jan Dušátko]

Dne 1.3.2017 v 1:17 Natanael napsal(a):
>
> Den 28 feb. 2017 14:59 skrev "Darren Moffat" <darren at nessieroo.com
> <mailto: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). 
>
Better to explain, XTS using two parameters. let's talk about index1 and
index2:
- 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.
- 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.

Also long key, could be explained as two keys (or first and second half)
- 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.
- 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.

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.

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.

> 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.
>
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography

-- 
Jan Dušátko

Phone:		+420 602 427 840
e-mail:		jan at dusatko.org
SkypeID:	darmodej
GPG:		http://www.dusatko.org/downloads/jdusatko.asc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170301/6ac6c4bb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jan.vcf
Type: text/x-vcard
Size: 242 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170301/6ac6c4bb/attachment.vcf>