From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (mail.tansi.org [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Fri, 5 Feb 2016 16:15:50 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-36-72.dclient.hispeed.ch [77.57.36.72]) by v6.tansi.org (Postfix) with ESMTPA id 9A36220DC530 for ; Fri, 5 Feb 2016 16:15:50 +0100 (CET) Date: Fri, 5 Feb 2016 16:15:50 +0100 From: Arno Wagner Message-ID: <20160205151550.GA32199@tansi.org> References: <56B20C05.7080307@gmail.com> <1454603376.4241.5.camel@debian.org> <20160204171753.GA20874@tansi.org> <1454653850.3573.2.camel@debian.org> <20160205110232.GD29709@tansi.org> <1454678001.21086.24.camel@debian.org> <20160205133123.GA31320@das-labor.org> <1454680178.7077.4.camel@das-labor.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1454680178.7077.4.camel@das-labor.org> Subject: Re: [dm-crypt] The future of disk encryption with LUKS2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Fri, Feb 05, 2016 at 14:49:38 CET, Zaolin wrote: > Hi, >=20 > > On Fri, Feb 05, 2016 at 14:13:21 CET, Yves-Alexis Perez wrote: > > > On ven., 2016-02-05 at 12:02 +0100, Arno Wagner wrote: > > > > > Think external drives / removable storage? > > > >=20 > > > > An attacker with physical access that you do not notice has=A0 > > > > won. Storage encryption does not protect here. Think, for=A0 > > > > example, "evil maid" type attacks. Storage encryption > > > > is only for theft of the device (which you notice) or=A0 > > > > attacker access which you notice in other ways. > > >=20 > > > This is exactly why integrity matters? The point is to have an usb > > > drive / > > > external disk *fully* encrypted.=A0=A0The decryption is done by the > > > host > > > (which is trusted).=A0=A0In that case, confidentiality and integrity > > > are both > > > important. > >=20 > > No. You are trying to solve the wrong problem. First, disk=A0 > > encryption with 1:1 mapping will never give you integrity=A0 > > protection and the other variants kill performance. > I partially agree. What's about using GCM or CCM mode of operation for > disk encryption ? ;) In order to solve the evil maid issue you need > hardware security and a secure boot process. GCM needs extra storage and so does CCM. The problem is that a simple entropy-argument shows that integrity protection is infeasible in the general case without extra storage. The effect is that unless you want to mess with effective disk block size (not a good idea), you do not get integrity protection in block-level disk encryption. On the other hand, there is a file-level alternative: eCryptFS. It serves somewhat different needs and has different performance characteristics. It basically does automated per-file PGP-like encryption. (The=20 format is even derived from PGP.) It does have some drawbacks=20 though, for example filenames, the filesystem (think evil maid)=20 and some metadata and information about file changes are not=20 protected. Regards, Arno --=20 Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of=20 "news" is "something that hardly ever happens." -- Bruce Schneier