1

It is known that the "xz" compression format embeds a checksum in the compressed file to verify integrity during decompression or standalone testing. The algorithm of the checksum can be one of: CRC32, CRC64, and SHA256, and the default is CRC64.

Now, we put an "xz" file into a XTS-encrypted disk image. The XTS mode is a pure confidentiality mode, and have no authenticity or integrity feature at all. But the "xz" file inside it has integrity feature. So the question is:

When combining the CRC64 integrity of "xz" with the confidentiality of XTS mode of operation, do we get a secure deterministic authenticated encryption (DAE, a.k.a. key-wrap) scheme?

DannyNiu
  • 9,207
  • 2
  • 24
  • 57
  • The integrity protection provided by xz is actually pretty bad, even if it were replaced by a cryptographic MAC: https://www.nongnu.org/lzip/xz_inadequate.html#unprot_len – forest Feb 09 '21 at 02:45

1 Answers1

6

No, this does not make a deterministic authenticated cipher, unless you're using a secret CRC as a MAC.

How do you break it? First, find a pair of messages $m = m_1 \mathbin\| m_2$ and $m' = m'_1 \mathbin\| m'_2$ so that $m_i \ne m'_i$ and $\operatorname{CRC}(m) = \operatorname{CRC}(m')$. (Finding collisions in CRCs is not hard.) Then:

  1. Query the oracle for $m_1 \mathbin\| m_2$ to find the ciphertext $c_1 \mathbin\| c_2 \mathbin\| c_3$; assume the CRC is in the plaintext of block $c_3$.
  2. Query the oracle for $m'_1 \mathbin\| m_2$ to find the ciphertext $c'_1 \mathbin\| c_2 \mathbin\| c_{\mathit{garbage}}$.
  3. Query the oracle for $m_1 \mathbin\| m'_2$ to find the ciphertext $c_1 \mathbin\| c'_2 \mathbin\| c_{\mathit{garbage}}$.

Finally, yield $c'_1 \mathbin\| c'_2 \mathbin\| c_3$ as a forgery, for the message $m'_1 \mathbin\| m'_2$ not previously sent to the oracle.

Squeamish Ossifrage
  • 48,392
  • 3
  • 116
  • 223