As far as I understand, the biggest problem of requesting authentication in disk encryption is that the plaintext and ciphertext are not having the same size -because of tag-. The XTS mode is already designed with this issue in mind (length preserved). However, as far as I know, it is not possible to preserve the size with authentication. Is it possible to solve this problem with disk type? Advanced format disks -such as 520, 528, 4112, 4160 and 4224 bytes- are said to have extra spaces for data integrity. Is it appropriate to solve this problem with these special sector size disks? What is the accessibility of these disks? – cost, availability etc. – While considering file systems, operating systems, development cards, older systems etc. what would you say about compatibility and interoperability of these disks?
-
2$\begingroup$ Is the extra space in the disk sector needed for (noncryptographical) error correction? Would it still be needed for that purpose? If so, well, you can't use that for another purpose (without losing the reliability that the error correction affords). Now, it might be possible to combine error correction and integrity check - however, that would be quite nonstandard... $\endgroup$– ponchoCommented Feb 17, 2023 at 13:04
-
$\begingroup$ Thank you for your response. Actually I didn't consider the error correction when asking this question. The extra space is defined as "integrity space" and I considered it as "cryptographic data integrity" and I thought maybe I can use this space for tag storage. I guess what is meant by data integrity here is making sure that data is readable, even when the write process is imperfect. $\endgroup$– NB_1907Commented Feb 23, 2023 at 7:46
1 Answer
This linked article from a related question explains pretty well the problems with full disk encryption (FDE) and why it "sucks".
TL;DR: It can't be fully randomized, leading to confidentiality problems, because it works on sectors whose tweaks remain constant for each sector and inner offset; it's ignorant of any higher level context / metadata & thus can't authenticate or use such as further randomization; it doesn't bother to authenticate data at all, let alone metadata, leaving it open to many well known attack vectors; and, it's inflexible.
As far as I know, there isn't a type of disk which includes native sector-level modification timestamps or MACs. If they did, I'd assume the randomization problem could be solved by injecting the timestamp as part of the tweak somehow. A native sector-level MAC could be better, as it would function like an SIV, helping to alleviate some randomization and authentication problems (though it would be a MAC of the plaintext, leaving other problems unsolved, including potential loss of data in the case of disk corruption).
TL;DR #2: The FDE problem is a pain in the metaphorical salt, that's kind of a last (and often weakest) line of defense, and which isn't really solvable at the sector level with the kinds of disks which are available on the market, nor without space overhead. What's used in practice is some combination of the following, depending on the needs of the user: Full-Disk Encryption as a line of defense against physical device seizure, filesystem encryption which functions like the former but has more flexibility in what it can do, the space it can use & the context data it has available, filesystem formats which handle integrity & error correction (special shoutout to ZFS), data redundancy to recovery from disk corruption, and application-level encryption for context-rich & context-specific cryptography.
-
$\begingroup$ "It can't be fully randomized, leading to confidentiality problems, because it works on sectors whose tweaks remain constant for each sector and inner offset"; actually, the question was "some raw disk formats do allow a little extra room, what can we do with that?". With that extra room, the standard objections to sector encryption (without any data expansion) go away, assuming, of course, that extra space isn't needed for something else (such as forward error correction, as in my comment) $\endgroup$– ponchoCommented Feb 17, 2023 at 16:18
-
$\begingroup$ Whoops, I did seriously misread the question. facepalm $\endgroup$– aiootpCommented Feb 17, 2023 at 18:42