From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czogKFa4jmN4 for ; Wed, 6 Feb 2013 13:52:43 +0100 (CET) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Wed, 6 Feb 2013 13:52:43 +0100 (CET) Received: by mail-we0-f169.google.com with SMTP id t11so1103145wey.14 for ; Wed, 06 Feb 2013 04:52:42 -0800 (PST) Message-ID: <51125218.6090709@gmail.com> Date: Wed, 06 Feb 2013 13:52:40 +0100 From: Milan Broz MIME-Version: 1.0 References: <20130206103238.GB11481@tansi.org> In-Reply-To: <20130206103238.GB11481@tansi.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Cryptographic issues with SSD-technology and wide-block encryption modes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 02/06/2013 11:32 AM, Arno Wagner wrote: > On Wed, Feb 06, 2013 at 11:06:11AM +0100, Stavros Kousidis wrote: >> 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. I am afraid this is not true for XTS. blocks inside XTS can be processed in parallel (so they cannot depend on each other) so the effect can be exactly opposite - first bit change in (the same) sector using e.g. CBC will change the whole ciphertext sector, while with XTS only first encryption block (16 bytes) is changed. I tried to show it here http://mbroz.fedorapeople.org/talks/DevConf2012/img6.jpg But despite that, XTS is usually better. But it would be nice to have some not patent encumbered wide mode (no code changes needed, just someone have to invent it and add to crypto API :-) Milan