From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.physik.uni-muenchen.de (mail.physik.uni-muenchen.de [192.54.42.129]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 20 Aug 2010 23:11:50 +0200 (CEST) From: Christoph Anton Mitterer In-Reply-To: <4C4FED84.3040201@redhat.com> References: <20100725103458.GA26486@tansi.org> <4C4C2D3C.40306@redhat.com> <1280063664.3309.119.camel@fermat.scientia.net> <4C4C4192.60908@redhat.com> <1280097464.3309.192.camel@fermat.scientia.net> <4C4CD361.4080000@redhat.com> <1280176686.3266.106.camel@fermat.scientia.net> <4C4E9CF4.3030308@redhat.com> <1280240110.11350.11.camel@etppc09.garching.physik.uni-muenchen.de> <4C4FED84.3040201@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 20 Aug 2010 23:11:48 +0200 Message-ID: <1282338708.3231.53.camel@fermat.scientia.net> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] XTS cipher mode limitations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Cc: Milan Broz Hi. Sorry for re-visiting this issue one (hopefully) last time... but at least to me not everything was fully clear yet. And I guess having a final conclusion which we could also put in the FAQ would be not to bad. With respect to XTS: 1) I guess we've already concluded that it's one of the securest modes available (if not the securest),... also protecting against certain attacks for which the others are vulnerable. 2) There was this IV boundary issue when using just "plain",... but this is effectively none, if one uses "plain64"... as this is enough for 2^64*512byte volumes. Right? 3) There was a limitation on the block size, used with XTS, right? But as we _always_ use 512 byte (even if the device below uses larger sectors), we're fine anyway. Right? 4) There was the (general issue) that if an attacker can make snapshots,... you can only write some amount of data (with the same key) until probability increases that attacks are possible, right? Is this only the case when he can make snapshots? In XTS, this starts to get a problem after about 100TB (IIRC) of data have been written, right? So the "solution" to this is: periodic re-encoding 5) Not sure whether I just didn't understand this,... but was'n there another limit with respect to about 1TB? And what was that about? So in the end we could put in the FAQ, that with XTS: - users should use plain64 - periodically re-encode before about 100TB - 1TB thingy?! Are there any other general things one should consider? (Of course I assume, that attackers have no easier way, e.g. via internet/software exploits or via physical force) Thanks, Chris. btw: On Wed, 2010-07-28 at 10:42 +0200, Milan Broz wrote: > Maybe one day it will be there but probably as part of LVM > (which will use libcryptsetup for key management for encrypted > logical volumes). > > It is possible to encode some simple function to reencode disk > in-place. But I would like to have something better, LVM > already provides most of infrastructure for such block device > operations. (beware: I am also lvm developer:) And? Already started coding? ;) btw2: Point (3) leads me to a different question. Imagin I have a disk with 4k sectors, put dm-crypt on it,... then the logical ones are 512 byte sectors, right? Now I put another layer or a filesystem on top. What happen's to the alignment now? Will it use 4k or 512 bytes?