How reassuring is CRC-then-XTS as authenticated encryption? 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?
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:


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$.
Query the oracle for $m'_1 \mathbin\| m_2$ to find the ciphertext $c'_1 \mathbin\| c_2 \mathbin\| c_{\mathit{garbage}}$.
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.