Reviewer: Sven Laur Article: Storage media encryption Author: Mart S~omermaa Short summary The article gives overview of existing blockcipher modes and their applicability in storage media encryption. The general impression is good, as the article covers most important aspects of low-level filesystem encryption and has plenty of further references for an eager reader. On the other hand, the article looks very scattered and lengthy (The suggested page limit has been exceeded by a factor of two). Also, the notations are in the beginning undefined or just confusing. Therefore, I suggest to split the article into two halves (surveys). The first should contain analysis of traditional blockcipher modes and the second should give an overview of tweakable blockcipher modes. Anyhow, the section 5 is too brief and should be extended further, or otherwise it has no informational content. General remarks In the scientific community it is common to prefer published papers to web pages, as it is impossible to reliably archive web. Hence, one should always use references to published papers even if there is a more extended version available in a web archive like ePrint. Moreover, the DBLP bibliography server http://www.informatik.uni-trier.de/~ley/db/index.html provides easy way to harvest correct BibTeX references. The second general remark is about presentation style. Low-level filesystem encryption might interest people far from cryptography and therefore I suggest to use more natural notations and terms. For example, strong pseudorandom functions and their security implications are evident only for crypto gurus. I suggest to explicitly state two goals: confidentiality and non-malleability, and then analyse which blockcipher modes satisfy these goals. Detailed comments Section 1 should state the main goals of storage encryption algorithms. For me it is not evident that encryption scheme should provide integrity (non-malleability). Section 2 is incorrectly structured, contains awful and undefined notations. First, note that Section 2 and Section 2.1 contain many redundant definitions. Namely, it does not make sense to define blockcipher modes and the security separately. Section 2 should start with the explanation what is a filesystem sector and blocks, then state the main requirements to the encryption algorithm, e.g it should be length preserving and randomly accessible, and finally give formal definitions of blockcipher modes. Symbols $\mathcal{Z},\mathcal{S}$ are undefined. It would be reasonable to use $Z_1,\ldots,Z_{T}$ instead of fuzzy notation of totally ordered set (such formalism is completely unnecessary). The use of sub- and superscripts is overwhelming and confusing. Triple c,p,c is evident typo. It would be more natural to use x or m as a plaintext, since p usually denotes a prime number. indistinguishable --> computationally indistinguishable. The notion of strong pseudorandom permutation does not have an interpretation for most readers. Besides it is incorrectly defined. A permutation is strong pseudorandom permutation, if it secure even limited number of black-box encryption and decryption calls are allowed. The latter is not equivalent to requirement that f and f^{-1} are pseudorandom permutations. Section 2.2 should be moved to Section 3. Section 3 I would use terms: not prp-secure --> does not assure confidentiality not +prp-secure --> is malleable Secondly, it is traditional to read formulas from left to right and not the other way around, thus a=b+c is more natural than b+c->a. Also, it would be wise to give names to vulnerabilities. The name 3.2.1 is not very mnemonic. It is not self-evident that +prp-secure a priori implies non-malleability. One should give more detailed reasoning in Section 2. Finally, I suggest to write attack descriptions in a more human readable way. They are rigorously formalised and that makes them hard to read and understand. I suggest to give more a literal description without formal division into input and result phase. Section 3.2 Vulnerability 3.2.1: Why is it important that p_{i-1}' is pseudorandom? Vulnerability 3.2.2: Write the proof in more condensed form. Actually, there is no need for the proof at all. Section 3.3 Vulnerability 3.3.1 --> block disclosure/leakage. Section 3.6 The conclusion 3.6 is a bit far-fetched, as the author implicitly assumes that the same tweaks are used for every sector again. The latter might be quite practical but still unjustified claim in theory. Section 4 Again, I would use name water-marking or controllable collisions instead of Vulnerability 4.1.1. Also, the formulas are incorrectly aligned. In case of large equation array, formulae are written a = g+h = c+d ... = m+g. Also, using sentences instead of => would make the text more readable. Section 4.2 I would say that the encryption mode does not provide confidentiality instead of saying that it is not prp-secure. --------------------------------------------------------------------- Second survey Section 5 The overall style is too rigid and formal. No intuition why the blockcipher modes have such internal structure is given. Also, there is no practical comparison of encryption decryption speeds of various modes. Section 5.1 The specification of EME and Figure 7 are not consistent. Is m=3 or that is just a bad coincidence (then add m=3 into the caption of Fig 7). Anyhow, this is really confusing. What is the meaning of L, as it is common for all sectors, and thus can be eliminated from the further analysis? We can consider $P_1\oplus L$ as an input, i.e. removing the first and last layer of EME does not increase security against differential cryptanalysis. Sections 5.2-5.4 Add more comments and insights about the tweakable blockcipher modes. Why did not you consider blockcipher modes XE and XEX? Phillip Rogaway, Efficient Instantiations of Tweakable Blockciphers and Refinements to Modes OCB and PMAC. Section 5.4 Storage media corruption is not really an issue, since MAC codes are usually added to the end of message. Hence, even complete deletion of MAC code do not affect decryption. If encrypted blocks are corrupted, then it is impossible to decrypt them anyway. Section 6 I do not agree with the claim that file system encryption should provide both confidentiality and non-malleability. I think that confidentiality is enough, since assuring the integrity is a separate task and there are plenty of other methods like MAC-s and hashes (Tripwire) to achieve reasonable security guarantees. Otherwise, the section is nicely written. Function E(E(K,T),T) must be a PRF or otherwise we could break E, by querying K_T=E(K,T) and then computing E(K_T,T). Standard hybrid argument. ----------------------------------------------------------------------- Personal opinion Personally, I do not think that low-level file system encryption is relevant at all in the long run, as it would be more natural to encrypt the data transferred between CPU and hard drive, i.e. use authenticated DH key-exchange at the boot time. The content of the hard drive can be protected by a physical design of hard drive, e.g. physical opening of hard drive destroys completely the storage media. (The principle of resurrecting duck can completely alleviate problem of switching hard drives, i.e. when hard drive is introduced to a new CPU, it is automatically formatted) Secondly, I do not think that tweakable blockcipher encryption mode is so relevant in the case of low level encryption. Current hard drives are large enough to implement elephant file system, e.g. file system where no files are deleted or modified (Periodic modification can use two keys). Thus, one can use simple counter mode to encipher files without any security concerns. Recall that the troubles with low-level encryption raise from the fact that we try to implement secure two-time pad that is inherently impossible. Of course, such encrypted filesystems are not universally suitable, for example they would not work with large databases. Nevertheless, such an approach is quite reasonable for ordinal home user. Moreover, if one sacrifices a 128 bits from each sector, then one can rewrite sectors by updating counter and thus alleviate the problem of file fragmentation.