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 at saout.de>http://www.saout.de/mailman/listinfo/dm-crypt
--
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