Subject: [Cfrg] Question about XTS mode

From: "Dr. Pala" <[email-masked]>
Date: Wed, 6 Apr 2016 11:01:04 -0300

Hi all,

I wanted to ask a small question on the list - I hope it is not too much 
off topic. I was talking with Rich Saltz and Jim Shaad about using the 
AES in XTS mode and I have a couple of concerns about the security of 
the encryption key for which we did not have a definitive answer.

In particular, I was wondering if re-using the encryption key might be a 
problem in this case (usually it is a bad idea for any stream-like 
ciphers) since I am not familiar with the internals of XTS (i.e., 
encrypting different files with the same key is safe or does it provides 
a security risk ?).

Last question I have is about the different security characteristics of 
XTS and CRT - are they practically equivalent ?

Thanks,

-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca

---

From: Natanael <[email-masked]>
Date: Wed, 6 Apr 2016 16:22:36 +0200

> I wanted to ask a small question on the list - I hope it is not too much
off topic. I was talking with Rich Saltz and Jim Shaad about using the AES
in XTS mode and I have a couple of concerns about the security of the
encryption key for which we did not have a definitive answer.
> In particular, I was wondering if re-using the encryption key might be a
problem in this case (usually it is a bad idea for any stream-like ciphers)
since I am not familiar with the internals of XTS (i.e., encrypting
different files with the same key is safe or does it provides a security
risk ?).

XTS behaves like a block cipher, not like a stream cipher.

Multiple encryptions under the same key will have the same result as ECB on
a per-block basis (it is deterministic), you can see if a previous
ciphertext / plaintext reoccurs in the exact same place. Across blocks,
this isn't possible (so moving a file within the encrypted volume is
indistinguishable from two random writes).

This is because XTS within a disk block first encrypts the block's number,
as well as each cipher block's number within the disk block (a 1k disk
block fits 8x 128 bit cipher blocks), and then uses that as an input for
the final encryption of the plaintext (it's like a full-disk key schedule,
every cipher block got a unique salt).

For local encryption, no problem. For storage on cloud services, attacks
like selective roll-back of individual blocks is possible due to lack of
ciphertext authentication (sign your encrypted volume before backup to
avoid this), and you'll reveal a lot of usage statistics if you sync
changes often, such as if/when you delete files (frequent reoccurances of
zeroed blocks).

But the plaintext won't leak, neither will the key.

---

From: lvh <[email-masked]>
Date: Wed, 6 Apr 2016 09:39:05 -0500

Hi,

> On Apr 6, 2016, at 9:01 AM, Dr. Pala <[email-masked]> wrote:
> 
> Hi all,
> 
> I wanted to ask a small question on the list - I hope it is not too much off topic. I was talking with Rich Saltz and Jim Shaad about using the AES in XTS mode and I have a couple of concerns about the security of the encryption key for which we did not have a definitive answer.
> 
> In particular, I was wondering if re-using the encryption key might be a problem in this case (usually it is a bad idea for any stream-like ciphers) since I am not familiar with the internals of XTS (i.e., encrypting different files with the same key is safe or does it provides a security risk ?).

I would recommend reading more about the internals of XTS, as I imagine this will clear stuff up. I recommend starting with Rogaway’s XEX paper, then moving on to XTS (say, the NIST spec).

When you’re talking about bad consequences of reusing keys, I’m assuming you’re referring to reusing _keystreams_ as produced by CTR-interpreted-as-a-synchronous-stream-cipher, since reusing keys is fine as long as you don’t reuse nonces. That’s not really a problem XTS has: XTS does not work like a stream cipher, but more like a very very wide block cipher; two different inputs with the same key and tweak (~sector number for FDE) won’t have any relation as they would with two different inputs with the same key and nonce in CTR mode.

> Last question I have is about the different security characteristics of XTS and CRT - are they practically equivalent ?

As above; definitely not :)

lvh

> Thanks,
> 
> -- 
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg