How can XTS be used to detect the presence of TrueCrypt hidden volumes? According to a thread on the VeraCrypt discussion forum, and a single-post followup, it is possible to detect the presence of a hidden volume in certain conditions due to a flaw in the cryptography or the way it is used, rather than a flaw in the software implementation. The fix was to use random data rather than zeros for the plaintext of the hidden volume header. When a hidden volume is in use, the area where the header for the hidden volume is populated and encrypted. When there is no hidden volume, it is initialized with zeros and encrypted. All encryption uses XTS mode. A post in that thread explains my concern:


  I'm somewhat worried about the possibility to distinguish encrypted data from uniformly distributed random data in general, because this could possibly hint some issue with the ciphers or their usage. If even a rather short block of encrypted zeros can be distinguished from random data, what about larger chunks of plaintext which show distinctive patterns (e.g. a 1 GB file of zeros), or plaintext chosen by or known to the attacker? Could they possibly also be detected in the ciphertext?
  
  I think it could be at least worth investigating why a block of XTS encrypted zeros could be distinguished from an XTS encrypted header, or random data.


And another post with speculation on an issue with XTS:


  My personal opinion is that the presence of 255 consecutive blocks of zeros encrypted by XTS next to a single block different from zero is the key point behind this issue, and that this enables somehow to have a statistical distinguisher for this special case.


I cannot imagine how the design of XTS could lead to that behavior.



Typically, disclosures done in this manner tend to be disclosures of software vulnerabilities which can be found without a large amount of skill. A fundamental flaw in XTS would require far more expertise and would be the sort of thing reported in a groundbreaking research paper, not in an email thread to the author of a single encryption product which uses XTS.

Obviously, the issue isn't a distinguishability attack against the cipher itself, but with how XTS is being used. I do not know enough about XTS to tell what the issue is, but the reported problem seems to violate XTS' cryptographic guarantees. My questions:


How could the presence of 255 consecutive zero blocks and a single non-zero block encrypted with XTS be distinguished, without the key, from the presence of any other 256 arbitrary blocks?
Is this a known issue? At the time of the last post on that thread, no more information about the attack was revealed, and the thread died in 2016 with little extra coverage.
Could this be a hoax or otherwise entirely false? It would seem that XTS, while not extremely simple, is simple enough that the described attack could be trivially independently discovered.
Could the issue be completely unrelated to XTS, for example caused by an implementation issue? This seems unlikely as dm-crypt, which uses proper XTS, works with TrueCrypt.


This issue, if true, seems very severe. I'd love to hear from some actual cryptographers.
They don't issue cryptographer's licenses to pseudonymous carrion fowl, so I can't rightly claim to be a cryptographer, but I can confidently say that if there is any problem here it is far more likely to arise from unrelated mistakes in VeraCrypt's protocol or implementation than in cryptanalysis of AES-XTS.  Any distinguisher on AES-XTS implies a nearly-as-good distinguisher on AES itself, and the difference is so small for a number of queries so far below the birthday bound as this that effectively it would mean someone has broken AES.