From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wy0-f178.google.com (mail-wy0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Wed, 27 Apr 2011 10:40:18 +0200 (CEST) Received: by wyb33 with SMTP id 33so1297283wyb.37 for ; Wed, 27 Apr 2011 01:40:17 -0700 (PDT) MIME-Version: 1.0 Date: Wed, 27 Apr 2011 10:40:17 +0200 Message-ID: From: Samantha Adams Content-Type: multipart/alternative; boundary=000e0ce0ccb0e19d8c04a1e26394 Subject: [dm-crypt] Use of GCM mode with dm-crypt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --000e0ce0ccb0e19d8c04a1e26394 Content-Type: text/plain; charset=ISO-8859-1 I would like to continue the post from December 2010 concerning GCM as it seems to be one of the few available modes to provide data integrity. It is true that GCM adds the authenication tag in every sector and as result we are going to have a sector bigger in size. So, it makes it unsuitable for use with dmcrypt. But is it possible to allocate some space elsewhere for the tag ? Are they any possible modifications we could make so we could use gcm with dmcrypt ? --000e0ce0ccb0e19d8c04a1e26394 Content-Type: text/html; charset=ISO-8859-1

I would like to continue the post from December 2010 concerning GCM as it seems to be one of the few available modes to provide data integrity.

It is true that GCM adds the authenication tag in every sector and as result we are going to have a sector bigger in size. So, it makes it unsuitable for use with dmcrypt.

But is it possible to allocate some space elsewhere for the tag ? Are they any possible modifications we could make so we could use gcm with dmcrypt ?

--000e0ce0ccb0e19d8c04a1e26394-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 27 Apr 2011 11:41:10 +0200 (CEST) Message-ID: <4DB7E4AD.3030906@redhat.com> Date: Wed, 27 Apr 2011 11:41:01 +0200 From: Milan Broz MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] Use of GCM mode with dm-crypt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Samantha Adams Cc: dm-crypt@saout.de On 04/27/2011 10:40 AM, Samantha Adams wrote: > I would like to continue the post from December 2010 concerning GCM > as it seems to be one of the few available modes to provide data > integrity. > > It is true that GCM adds the authenication tag in every sector and as > result we are going to have a sector bigger in size. So, it makes it > unsuitable for use with dmcrypt. Exactly. dmcrypt provides just transparent encryption so the ciphertext device and plaintext device is of the same size, we have no space to store authentication tag to. > But is it possible to allocate some space elsewhere for the tag ? Are > they any possible modifications we could make so we could use gcm > with dmcrypt ? Basically it would be new encryption DM target (it can share code but the mapping here is different). The crucial question where do you want to store authentication tag... If there is some standard way, perhaphs it can be done. But isn't better to provide these integrity services to filesystem on top of dmcrypt? (so fs can allocate blocks storing integrity info) Milan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v4.tansi.org (ns.km33513-03.keymachine.de [87.118.94.3]) by mail.saout.de (Postfix) with ESMTP for ; Wed, 27 Apr 2011 15:43:24 +0200 (CEST) Received: from gatewagner.dyndns.org (84-74-164-52.dclient.hispeed.ch [84.74.164.52]) by v4.tansi.org (Postfix) with ESMTPA id 98E01205703 for ; Wed, 27 Apr 2011 15:43:24 +0200 (CEST) Date: Wed, 27 Apr 2011 15:43:23 +0200 From: Arno Wagner Message-ID: <20110427134323.GA27463@tansi.org> References: <4DB7E4AD.3030906@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DB7E4AD.3030906@redhat.com> Subject: Re: [dm-crypt] Use of GCM mode with dm-crypt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Wed, Apr 27, 2011 at 11:41:01AM +0200, Milan Broz wrote: > On 04/27/2011 10:40 AM, Samantha Adams wrote: [...] > Basically it would be new encryption DM target (it can share code > but the mapping here is different). > > The crucial question where do you want to store authentication tag... > If there is some standard way, perhaphs it can be done. > > But isn't better to provide these integrity services to filesystem > on top of dmcrypt? (so fs can allocate blocks storing integrity info) In my view, integrity check, just as compression (and the filesystem itself) all belong on top of encryption. For the other two, this is obvious. For the integrity check, what is the FS layer to do if it fails? If you have error correction or redundancy in the FS, then it can do something, but on crypto-layer you can just propagate the error and handling would be done elsewhere. Also note that the problem of storing the tags.checksums goes away on the FS layer, as one of the primary tasks of a FS is storing metadata. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 3 May 2011 14:22:24 +0200 (CEST) Received: by wwa36 with SMTP id 36so12788wwa.1 for ; Tue, 03 May 2011 05:22:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110427134323.GA27463@tansi.org> References: <4DB7E4AD.3030906@redhat.com> <20110427134323.GA27463@tansi.org> Date: Tue, 3 May 2011 14:22:23 +0200 Message-ID: From: Samantha Adams Content-Type: multipart/alternative; boundary=000e0ce0b13238f43f04a25e31d8 Subject: Re: [dm-crypt] Use of GCM mode with dm-crypt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --000e0ce0b13238f43f04a25e31d8 Content-Type: text/plain; charset=ISO-8859-1 Probably the best solution is to check integrity in the FS layer. Concerning gcm, in my opinion, it's a pity that we can't use an AE mode onf encryption because in this way we would be able to also check data authenticity. Anyway, thank you all for you answers ! :) Sam On Wed, Apr 27, 2011 at 3:43 PM, Arno Wagner wrote: > On Wed, Apr 27, 2011 at 11:41:01AM +0200, Milan Broz wrote: > > On 04/27/2011 10:40 AM, Samantha Adams wrote: > [...] > > Basically it would be new encryption DM target (it can share code > > but the mapping here is different). > > > > The crucial question where do you want to store authentication tag... > > If there is some standard way, perhaphs it can be done. > > > > But isn't better to provide these integrity services to filesystem > > on top of dmcrypt? (so fs can allocate blocks storing integrity info) > > In my view, integrity check, just as compression (and the filesystem > itself) all belong on top of encryption. For the other two, this is > obvious. For the integrity check, what is the FS layer to do if it > fails? If you have error correction or redundancy in the FS, then > it can do something, but on crypto-layer you can just propagate the > error and handling would be done elsewhere. Also note that the > problem of storing the tags.checksums goes away on the FS layer, > as one of the primary tasks of a FS is storing metadata. > > Arno > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: > arno@wagner.name > GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 > 338F > ---- > Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans > > If it's in the news, don't worry about it. The very definition of > "news" is "something that hardly ever happens." -- Bruce Schneier > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt > --000e0ce0b13238f43f04a25e31d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Probably the best solution is to check integrity in the FS layer.

Co= ncerning gcm, in my opinion, it's a pity that we can't use an AE mo= de onf encryption because in this way we would be able to also check data a= uthenticity.

Anyway, thank you all for you answers ! :)

Sam

On Wed, Apr 27, 2011 at 3:43 PM, Arno Wagner <arno@wagner.name> wrote:
On Wed, Apr 27, 2011 at 1= 1:41:01AM +0200, Milan Broz wrote:
> On 04/27/2011 10:40 AM, Samantha Adams wrote:
[...]
> Basically it would be new encryption DM target (it c= an share code
> but the mapping here is different).
>
> The crucial question where do you want to store authentication tag...<= br> > If there is some standard way, perhaphs it can be done.
>
> But isn't better to provide these integrity services to filesystem=
> on top of dmcrypt? (so fs can allocate blocks storing integrity info)<= br>
In my view, integrity check, just as compression (and the filesystem<= br> itself) all belong on top of encryption. For the other two, this is
obvious. For the integrity check, what is the FS layer to do if it
fails? If you have error correction or redundancy in the FS, then
it can do something, but on crypto-layer you can just propagate the
error and handling would be done elsewhere. Also note that the
problem of storing the tags.checksums goes away on the FS layer,
as one of the primary tasks of a FS is storing metadata.

Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: =A0ID: 1E25338F =A0FP: 0C30 5782 9D93 F785 E79C =A00296 797F 6B50 1E= 25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. =A0The very definition o= f
"news" is "something that hardly ever happens." -- Bruc= e Schneier
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt

--000e0ce0b13238f43f04a25e31d8-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-fx0-f50.google.com (mail-fx0-f50.google.com [209.85.161.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 3 May 2011 14:46:46 +0200 (CEST) Received: by fxm16 with SMTP id 16so61749fxm.37 for ; Tue, 03 May 2011 05:46:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <4DB7E4AD.3030906@redhat.com> <20110427134323.GA27463@tansi.org> Date: Tue, 3 May 2011 05:46:45 -0700 Message-ID: From: Will Drewry Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dm-crypt] Use of GCM mode with dm-crypt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Samantha Adams Cc: dm-crypt@saout.de FWIW, putting integrity checking at the filesystem layer should be done carefully as well. If your threat model includes attacks resulting from attacker-controlled metadata, then you may still be exposed to a variety of issues in the filesystem layer itself (even if it is difficult for an attacker to do reliably given how great dm-crypt is :). I've had good experience layering a dm target for block-level integrity checking under the fs layer as it avoids the risks associated and gets all the nice benefits of the block cache, etc. (The target my project uses isn't upstream yet, but after a lot of in-progress cleanup, we hope it will be![1]). The approach should layer just fine with dm-crypt as well. Anyway, just my two cents. Cheers! will 1 - http://git.chromium.org/gitweb/?p=3Dchromiumos/third_party/kernel.git;a= =3Dblob;f=3DDocumentation/device-mapper/dm-verity.txt On Tue, May 3, 2011 at 5:22 AM, Samantha Adams wrot= e: > Probably the best solution is to check integrity in the FS layer. > > Concerning gcm, in my opinion, it's a pity that we can't use an AE mode o= nf > encryption because in this way we would be able to also check data > authenticity. > > Anyway, thank you all for you answers ! :) > > Sam > > On Wed, Apr 27, 2011 at 3:43 PM, Arno Wagner wrote: >> >> On Wed, Apr 27, 2011 at 11:41:01AM +0200, Milan Broz wrote: >> > On 04/27/2011 10:40 AM, Samantha Adams wrote: >> [...] >> > Basically it would be new encryption DM target (it can share code >> > but the mapping here is different). >> > >> > The crucial question where do you want to store authentication tag... >> > If there is some standard way, perhaphs it can be done. >> > >> > But isn't better to provide these integrity services to filesystem >> > on top of dmcrypt? (so fs can allocate blocks storing integrity info) >> >> In my view, integrity check, just as compression (and the filesystem >> itself) all belong on top of encryption. For the other two, this is >> obvious. For the integrity check, what is the FS layer to do if it >> fails? If you have error correction or redundancy in the FS, then >> it can do something, but on crypto-layer you can just propagate the >> error and handling would be done elsewhere. Also note that the >> problem of storing the tags.checksums goes away on the FS layer, >> as one of the primary tasks of a FS is storing metadata. >> >> Arno >> -- >> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: >> arno@wagner.name >> GnuPG: =A0ID: 1E25338F =A0FP: 0C30 5782 9D93 F785 E79C =A00296 797F 6B50= 1E25 >> 338F >> ---- >> Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans >> >> If it's in the news, don't worry about it. =A0The very definition of >> "news" is "something that hardly ever happens." -- Bruce Schneier >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@saout.de >> http://www.saout.de/mailman/listinfo/dm-crypt > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt > >