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?


1 Answer 1


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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.