Re: [dm-crypt] [dm-devel] dm-crypt performance

[Arno Wagner <arno@wagner.name>]

On Tue, Apr 09, 2013 at 02:08:59PM -0400, 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...)

I think they are not really preventable. From what I have seen in
reseach, with an user on the same machine, timing attacke may be
extremely hard to prevent.

As long as the attacker sits on the same hardware or has a low-jitter
connection to it, he can do very precise measurements. Eventually, 
this will have to be solved by cipher implementation techniques. 
Aniother problem is that operations that look like they are data
independent can turn out to actually be data dependent. 

> So use serpent - it is implemented without any data-dependent lookup 
> tables, so it has no timing attacks.

That is what people think at this time. Competent people thought there
were no timing attacks on AES in 2000 as well. And there is the
problem that Serpent is not as well scrutinized as AES at this time
and that is likely to get worse. So it may have other problems.

> AES uses data-dependent lookup tables, on CPU with hyperthreding, the 
> second thread can observe L1 cache footprint done by the first thread and 
> get some information about data being encrypted...

Yes, but that is not the only potential problem. For example, with 
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 
while feasible, they are sloooooooowwwwww...

Arno
-- 
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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare