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 D3Z00pNYE3Rg for ; Tue, 9 Apr 2013 20:59:31 +0200 (CEST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Tue, 9 Apr 2013 20:59:31 +0200 (CEST) Received: by mail-ee0-f47.google.com with SMTP id t10so3037240eei.34 for ; Tue, 09 Apr 2013 11:59:30 -0700 (PDT) Message-ID: <5164650F.50405@gmail.com> Date: Tue, 09 Apr 2013 20:59:27 +0200 From: Milan Broz MIME-Version: 1.0 References: <20130326122713.GC27610@agk-dp.fab.redhat.com> <5151FF82.6090405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] [dm-devel] dm-crypt performance List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mikulas Patocka Cc: Mike Snitzer , dm-crypt@saout.de, Christian Schmidt , linux-kernel@vger.kernel.org, Christoph Hellwig , dm-devel@redhat.com, Andi Kleen , Milan Broz On 9.4.2013 20:08, Mikulas Patocka wrote: > > > On Tue, 26 Mar 2013, Milan Broz wrote: > >> - Are we sure we are not inroducing some another side channel in disc >> encryption? (Unprivileged user can measure timing here). >> (Perhaps stupid reason but please do not prefer performance to security >> in encryption. Enough we have timing attacks for AES implementations...) > > So use serpent - it is implemented without any data-dependent lookup > tables, so it has no timing attacks. I wish using something different than AES is just such simple technical issue for many people. But e.g. just try it in FIPS mode where AES is the only option:-) Anyway, using bio_associate_current() seems to be the right way to try now... Milan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Milan Broz Subject: Re: [dm-crypt] [dm-devel] dm-crypt performance Date: Tue, 09 Apr 2013 20:59:27 +0200 Message-ID: <5164650F.50405@gmail.com> References: <20130326122713.GC27610@agk-dp.fab.redhat.com> <5151FF82.6090405@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Mikulas Patocka Cc: Milan Broz , Mike Snitzer , dm-crypt@saout.de, Christian Schmidt , linux-kernel@vger.kernel.org, Christoph Hellwig , dm-devel@redhat.com, Andi Kleen List-Id: dm-devel.ids On 9.4.2013 20:08, Mikulas Patocka wrote: > > > On Tue, 26 Mar 2013, Milan Broz wrote: > >> - Are we sure we are not inroducing some another side channel in disc >> encryption? (Unprivileged user can measure timing here). >> (Perhaps stupid reason but please do not prefer performance to security >> in encryption. Enough we have timing attacks for AES implementations...) > > So use serpent - it is implemented without any data-dependent lookup > tables, so it has no timing attacks. I wish using something different than AES is just such simple technical issue for many people. But e.g. just try it in FIPS mode where AES is the only option:-) Anyway, using bio_associate_current() seems to be the right way to try now... Milan