> An HTML attachment was scrubbed... > URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20130206/89e2ec35/attachment.html > [http://www.saout.de/pipermail/dm-crypt/attachments/20130206/89e2ec35/attachment.html]> Oops, forgot about the HTML web interface. Here's the plain text: ------------------------------------------------------------------------------- Dear Arno, dear Milan, I have seen that you are well aware of the SSD-technology drawbacks from a cryptographic viewpoint, e.g. http://www.saout.de/pipermail/dm-crypt/2012-August/002665.html http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html One essential issue that concerns full disk encryption on SSDs, that I have not seen in a mail discussion here so far (might be there and I simply missed it), is the distribution of an uncontrollable amount of copies of SSD-page contents (~4096 Bytes) where only a limited number of blocks (~16 Bytes) have changed. This is initiated by local changes in userspace data and technically due to the complex nature of the flash translation layer (mainly wear leveling techniques), the narrow-block encryption modes (here: XTS) and sector-wise constant IVs. In Cipher-block chaining mode the position where a bit-flip happened is visible in principle. A countermeasure to those history-building SSD-mechanisms is to blur what is written to the flash device by forcing a multi-sector-wide change when a bit changes (preferrably: multi-sector = size of file system blocks). There are two concrete realizations of that strategy that I know of: 1) Use random IVs. Leaves you with data expansion, since you have to store the IVs, and a pain in the *** effort to implement this reliably. 2) Add a (claimed patent free) wide-block mode like TET or HEHfp (see articles below) from the Hash-Encrypt-Hash family to the Crypto-API and change the dmcrypt crypto engine to handle variable block sizes instead of always operating on 512 Bytes of data (compare the discussion: http://www.saout.de/pipermail/dm-crypt/2011-April/001667.html) Another (great) advantage of those wide-block modes is their inherent 1/2*MAC functionality due to the intended collision avoidance in the encryption layer that is built in by the universal hash pre- and post-processing („1/2“ for: not a MAC but more than no MAC at all). Since you maintain the code I would like to know your opinion on this and if there is a chance to pursue such a project. Best Stavros P.S.: You can search the web for the above mentioned articles: TET: Shai Halevi, „Invertible universal hashing and the TET encryption mode“ HEHfp: Palash Sarkar, „Improving upon the TET mode of operation“ Those are instances of the hash-encrypt-hash family introduced by Naor and Reingold in „A pseudo-random encryption mode“. Halevi discusses the intellectual-property issues et the end of his article. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
