From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <corsac@debian.org>
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 BmMBe_L8Q0_z for <dm-crypt@saout.de>;
 Sun, 21 Apr 2013 22:39:20 +0200 (CEST)
Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [IPv6:2a01:e0c:1:1599::12])
 by mail.saout.de (Postfix) with ESMTP
 for <dm-crypt@saout.de>; Sun, 21 Apr 2013 22:39:20 +0200 (CEST)
Received: from molly.corsac.net (unknown [78.192.68.46])
 by smtp3-g21.free.fr (Postfix) with ESMTP id F1A32A6228
 for <dm-crypt@saout.de>; Sun, 21 Apr 2013 22:39:14 +0200 (CEST)
Message-ID: <1366576716.4048.13.camel@hidalgo>
From: Yves-Alexis Perez <corsac@debian.org>
Date: Sun, 21 Apr 2013 22:38:36 +0200
In-Reply-To: <20130409184054.GA28430@tansi.org>
References: <Pine.LNX.4.64.1303252051520.9745@file.rdu.redhat.com>
 <20130326122713.GC27610@agk-dp.fab.redhat.com> <5151FF82.6090405@gmail.com>
 <Pine.LNX.4.64.1304091352320.10025@file.rdu.redhat.com>
 <20130409184054.GA28430@tansi.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0
Subject: Re: [dm-crypt] [dm-devel] dm-crypt performance
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: Arno Wagner <arno@wagner.name>
Cc: dm-crypt@saout.de

On mar., 2013-04-09 at 20:40 +0200, Arno Wagner wrote:
> > AES uses data-dependent lookup tables, on CPU with hyperthreding, the=
=20
> > second thread can observe L1 cache footprint done by the first thread a=
nd=20
> > get some information about data being encrypted...
>=20
> Yes, but that is not the only potential problem. For example, with=20
> Intel now implementing voltage regulators on the CPU, we may
> even see power-usage based leaks. If you are paranoid, constant
> time-contant-power implementations are the only solution. And=20
> while feasible, they are sloooooooowwwwww...=20

Note that on those CPUs AES should usually use AES-NI so timing attacks
using the cache should not be that relevant=E2=80=A6

Regards,
--=20
Yves-Alexis