[dm-crypt] Cryptographic issues with SSD-technology and wide-block encryption modes

Stavros Kousidis dabros.kuhsadas at web.de
Wed Feb 6 11:06:11 CET 2013

> 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.


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.


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.

More information about the dm-crypt mailing list