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:24:41 +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 3995820DC530 for ; Fri, 5 Feb 2016 16:24:41 +0100 (CET) Date: Fri, 5 Feb 2016 16:24:40 +0100 From: Arno Wagner Message-ID: <20160205152440.GC32199@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@tansi.org> <1454684474.21086.30.camel@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1454684474.21086.30.camel@debian.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 16:01:14 CET, Yves-Alexis Perez wrote: > On ven., 2016-02-05 at 14:31 +0100, Arno Wagner wrote: > > 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. >=20 > I perfectly understand that, thank you. Again, I'm *well aware* of the ne= ed to > store integrity patterns somewhere. I'm *not* asking for 1:1 mapping. >=20 > Can I sincerely ask that you not consider at first (and second, and third) > that I didn't think first about what I was asking on the list? Then why are you asking about integrity protection on a list dedicated to a block-layer encryption system? That does not make any sense. If you state things that do not make sense then I will point that out, because there is a real possibility that your reasoning process (I am not implying there was none) was=20 flawed.=20 > > And second, who says anything abot the "evil maid" changing > > things in the encrypted container? >=20 > I'm not following you here. Attacks on hardware, replacement of the disk with something that attacks the boot process, Firewire, USB, etc. vulnerabilities,=20 changes in non-encrypted areas, etc.=20 > >=20 > > Seriosuly, what you want you do not do with disk encryption,=A0 > > but with PGP/GnuPG on file-level. >=20 > Because encrypting whole disk with GnuPG doesn't really scale, for > example? I have to admit I'm a bit puzzled by the question on this list, > to be honest. Use eCryptFS for a scalable implementation of that idea. In fact, eCryptFS uses a file-format derived from PGP,=20 and that is no accident. 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