On Wed, Feb 06, 2013 at 11:06:11AM +0100, Stavros Kousidis wrote: > > 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: > ------------------------------------------------------------------------------- Ah, thanks. I was just about to complain. > 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. I am aware of that issue. However, XTS mode should lead to a full sector (512 Bytes) chage even if only one bit is changed. That is the whole point of modes like XTS, EME, etc. > 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: I think you just have to live with it at this time. It is not a severe vulnerability in most situations. And it will not build up to badly, at some time the blocks get re-used. The amounth of spares/write pool in SSDs seems to be shrinking as well. > 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. It is. It also breaks the dm-model as additional accesses are required. Not an option, I think. > 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) I will have a look at the articles, but I think this is not really an option either, agen because of mismatch with the dm-layer. > 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. That would be Milan. I am just the volunteer that does the documentation. Milan actually gets paid for real work on cryotsetup. Arno > > 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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
