[dm-crypt] Cryptographic issues with SSD-technology and wide-block encryption modes
arno at wagner.name
Wed Feb 6 11:32:39 CET 2013
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.
> 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:
I will have a look at the articles, but I think this is not
really an option either, agen because of mismatch with the
> 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.
> 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 at saout.de
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
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
More information about the dm-crypt