AW: [PATCH v1 2/7] AES for PPC/SPE - aes tables

[Markus Stockhausen]

> Von: linux-crypto-owner at vger.kernel.org [linux-crypto-owner at vger.kernel.org]" im Auftrag von "Segher Boessenkool [segher at kernel.crashing.org]
> Gesendet: Montag, 16. Februar 2015 15:37
> An: David Laight
> Cc: Markus Stockhausen; linux-crypto at vger.kernel.org; linuxppc-dev at lists.ozlabs.org
> Betreff: Re: [PATCH v1 2/7] AES for PPC/SPE - aes tables
> 
> On Mon, Feb 16, 2015 at 02:19:50PM +0000, David Laight wrote:
> > From:  Markus Stockhausen
> > > 4K AES tables for big endian
> >
> > I can't help feeling that you could give more information about how the
> > values are generated.
> 
> ... and an explanation of why this does not open you up to a timing attack?

Good points,

the tables are only big endian reversed ones of those found in crypto/aes_generic.c.

Regarding timing attacks: I understand, that reducing AES table sizes for a constant 
AES processing time is important to avoid cache timing attacks. Hopefully the 
following points will mitigate the concern.

Target architecture are low performance e500 cores without available caam 
features. These can currently use only aes-generic module. That one depends 
on 16K T-tables. 2*4K for encryption and 2*4K for decryption. The new module
reduces the T-table sizes to 8K+256 bytes. Far away from a minimal 256 byte
S-BOX but at least an improvement.

To narrow it down further. Intended use is for cheap routers. So no multiuser 
environments where a malicous process could drive complex flush+reload 
attacks. In case someone gains unallowed access there will be a lot of other 
and simpler ways to compromise the system.

In case that is sufficient for you I will add respective notes into a patch v2.

Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: InterScan_Disclaimer.txt
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20150216/17c22cd2/attachment-0001.txt>