The AES-NI properties that XTS exploit can also be exploited by better wide-block-narrow-block constructions; Rogaway for instance suggests that XTS could have cleaned up the CTS construction by using a better understood Feistel construction.
Even better would be a "native" wide-block tweakable cipher, one that created a strong PRP out of the entire sector, rather than chunking the sector into narrow blocks and then ECB'ing those narrow blocks. However you did that, it would also probably involve invocations of the AES block transform, and thus benefit from AES-NI.
But you're right: XTS has a convenience advantage for encryption in the standard hardware block device setting. What's sad about that is that simulated hardware block encryption is actually not a particularly strong protection for users.
Comments
The AES-NI properties that XTS exploit can also be exploited by better wide-block-narrow-block constructions; Rogaway for instance suggests that XTS could have cleaned up the CTS construction by using a better understood Feistel construction.
Even better would be a "native" wide-block tweakable cipher, one that created a strong PRP out of the entire sector, rather than chunking the sector into narrow blocks and then ECB'ing those narrow blocks. However you did that, it would also probably involve invocations of the AES block transform, and thus benefit from AES-NI.
But you're right: XTS has a convenience advantage for encryption in the standard hardware block device setting. What's sad about that is that simulated hardware block encryption is actually not a particularly strong protection for users.
Have you checked Rogaway's AEZ? Its core could probably be repurposed to disk encryption, being an AES-based tweakable wide block cipher.
I remember reading this, but will admit to not having an immediate intuition for what it would look like as a wide-block disk encryption scheme.