every (nearly every?) disk encryption uses XTS, and I think we can do better (better security-wise).
in http://css.csail.mit.edu/6.858/2013/readings/bitlocker.pdf Niels Ferguson writes:
It is tempting to add a nonce or MAC value to the ciphertext. However,
making the ciphertext larger than the plaintext is not feasible. Both
the disk and the operating system work in sectors whose size is a
power of two. We could map a 512 byte OS sector into a 1024 byte
disk-sector, but that would entail the loss of half the disk capacity,
a price users are not willing to pay. We could reserve one in every 16
sectors to store the MAC and nonce values for the other 15 sectors,
but this has several problems. First of all, writing to sector x means
updating an additional sector that contains the nonce and MAC. This
turns a write into a read-then-write with the associated performance
loss. Furthermore, it could damage the nonce/MAC sector (e.g. if there
is a power failure), which would lead to the loss of the other 14 data
sectors; also unacceptable. Finally, for various usability,
manageability, and deployment reasons, it must be possible to enable
and disable BitLocker on an existing disk. (Think of a user upgrading
to a new Windows version that includes BitLocker and enabling
BitLocker on an existing disk.) Adding nonce/MAC sectors modifies the
disk layout (and reduces the amount of available disk space) making it
extremely complicated to enable and disable in-place. Add to that the
various failure modes that can happen during the conversion, and it
becomes infeasible to do this conversion in a reliable way. The final
conclusion is that we cannot add a MAC to each disk sector in a way
that would be acceptable to most users.
and yes, for general purpose consumer-grade disk encryption, this is certainly true.
but for you? for me? why not put the security first, and deal with the issues.
- so, reserve 1 in 16 sectors to store nonces and MACs.
- use an intent-log to recover after a power failure.