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

2015-02-16 Thread Markus Stockhausen
 Von: linux-crypto-ow...@vger.kernel.org 
 [linux-crypto-ow...@vger.kernel.org]quot; im Auftrag von quot;Segher 
 Boessenkool [seg...@kernel.crashing.org]
 Gesendet: Montag, 16. Februar 2015 15:37
 An: David Laight
 Cc: Markus Stockhausen; linux-cry...@vger.kernel.org; 
 linuxppc-dev@lists.ozlabs.org
 Betreff: Re: [PATCH v1 2/7] AES for PPC/SPE - aes tables
 
 On Mon, Feb 16, 2015 at 02:19:50PM +, 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
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.

Über das Internet versandte E-Mails können unter fremden Namen erstellt oder
manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine
rechtsverbindliche Willenserklärung.

Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln

Vorstand:
Kadir Akin
Dr. Michael Höhnerbach

Vorsitzender des Aufsichtsrates:
Hans Kristian Langva

Registergericht: Amtsgericht Köln
Registernummer: HRB 52 497

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

e-mails sent over the internet may have been written under a wrong name or
been manipulated. That is why this message sent as an e-mail is not a
legally binding declaration of intention.

Collogia
Unternehmensberatung AG
Ubierring 11
D-50678 Köln

executive board:
Kadir Akin
Dr. Michael Höhnerbach

President of the supervisory board:
Hans Kristian Langva

Registry office: district court Cologne
Register number: HRB 52 497


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

2015-02-16 Thread David Laight
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.

...
 + * These big endian AES encryption/decryption tables are designed to be 
 simply
 + * accessed by a combination of rlwimi/lwz instructions with a minimum
 + * of table registers (usually only one required). Thus they are aligned to
 + * 4K. The locality of rotated values is derived from the reduced offsets 
 that
 + * are available in the SPE load instructions. E.g. evldw, evlwwsplat, ...
 + *
 + */
 +.data
 +.align 12
 +.globl PPC_AES_4K_ENCTAB
 +PPC_AES_4K_ENCTAB:
 + .long 0xc66363a5,0xa5c66363,0x63a5c663,0x6363a5c6

These seem to be byte rotates (all down the table).
If so then use a CPP define to generate the rotated values.

I'd like to see a reference to where the values themselves come from.

 + .long 0xf87c7c84,0x84f87c7c,0x7c84f87c,0x7c7c84f8
...
 + .long 0x6dd6,0xd66d,0xbbd66dbb,0xd66d
 + .long 0x2c16163a,0x3a2c1616,0x163a2c16,0x16163a2c
 +.globl PPC_AES_4K_DECTAB
 +PPC_AES_4K_DECTAB:
 + .long 0x51f4a750,0x5051f4a7,0xa75051f4,0xf4a75051
...
 + .long 0xd0b85742,0x42d0b857,0x5742d0b8,0xb85742d0

Some explanation of this third dataset is also needed.

 + .byte 0x52, 0x09, 0x6a, 0xd5, 0x30, 0x36, 0xa5, 0x38
...
 + .byte 0xe1, 0x69, 0x14, 0x63, 0x55, 0x21, 0x0c, 0x7d

David

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

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

2015-02-16 Thread Markus Stockhausen
[PATCH v1 2/7] AES for PPC/SPE - aes tables

4K AES tables for big endian

Signed-off-by: Markus Stockhausen stockhau...@collogia.de

diff --git a/arch/powerpc/crypto/aes-tab-4k.S b/arch/powerpc/crypto/aes-tab-4k.S
new file mode 100644
index 000..6bc1755
--- /dev/null
+++ b/arch/powerpc/crypto/aes-tab-4k.S
@@ -0,0 +1,570 @@
+/*
+ * 4K AES tables for PPC AES implementation
+ *
+ * Copyright (c) 2015 Markus Stockhausen stockhau...@collogia.de
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+
+/*
+ * These big endian AES encryption/decryption tables are designed to be simply
+ * accessed by a combination of rlwimi/lwz instructions with a minimum
+ * of table registers (usually only one required). Thus they are aligned to
+ * 4K. The locality of rotated values is derived from the reduced offsets that
+ * are available in the SPE load instructions. E.g. evldw, evlwwsplat, ...
+ *
+ */
+.data
+.align 12
+.globl PPC_AES_4K_ENCTAB
+PPC_AES_4K_ENCTAB:
+   .long 0xc66363a5,0xa5c66363,0x63a5c663,0x6363a5c6
+   .long 0xf87c7c84,0x84f87c7c,0x7c84f87c,0x7c7c84f8
+   .long 0xee99,0x99ee,0x7799ee77,0x99ee
+   .long 0xf67b7b8d,0x8df67b7b,0x7b8df67b,0x7b7b8df6
+   .long 0xfff2f20d,0x0dfff2f2,0xf20dfff2,0xf2f20dff
+   .long 0xd66b6bbd,0xbdd66b6b,0x6bbdd66b,0x6b6bbdd6
+   .long 0xde6f6fb1,0xb1de6f6f,0x6fb1de6f,0x6f6fb1de
+   .long 0x91c5c554,0x5491c5c5,0xc55491c5,0xc5c55491
+   .long 0x60303050,0x50603030,0x30506030,0x30305060
+   .long 0x02010103,0x03020101,0x01030201,0x01010302
+   .long 0xce6767a9,0xa9ce6767,0x67a9ce67,0x6767a9ce
+   .long 0x562b2b7d,0x7d562b2b,0x2b7d562b,0x2b2b7d56
+   .long 0xe7fefe19,0x19e7fefe,0xfe19e7fe,0xfefe19e7
+   .long 0xb5d7d762,0x62b5d7d7,0xd762b5d7,0xd7d762b5
+   .long 0x4dababe6,0xe64dabab,0xabe64dab,0xababe64d
+   .long 0xec76769a,0x9aec7676,0x769aec76,0x76769aec
+   .long 0x8fcaca45,0x458fcaca,0xca458fca,0xcaca458f
+   .long 0x1f82829d,0x9d1f8282,0x829d1f82,0x82829d1f
+   .long 0x89c9c940,0x4089c9c9,0xc94089c9,0xc9c94089
+   .long 0xfa7d7d87,0x87fa7d7d,0x7d87fa7d,0x7d7d87fa
+   .long 0xeffafa15,0x15effafa,0xfa15effa,0xfafa15ef
+   .long 0xb25959eb,0xebb25959,0x59ebb259,0x5959ebb2
+   .long 0x8e4747c9,0xc98e4747,0x47c98e47,0x4747c98e
+   .long 0xfbf0f00b,0x0bfbf0f0,0xf00bfbf0,0xf0f00bfb
+   .long 0x41adadec,0xec41adad,0xadec41ad,0xadadec41
+   .long 0xb3d4d467,0x67b3d4d4,0xd467b3d4,0xd4d467b3
+   .long 0x5fa2a2fd,0xfd5fa2a2,0xa2fd5fa2,0xa2a2fd5f
+   .long 0x45afafea,0xea45afaf,0xafea45af,0xafafea45
+   .long 0x239c9cbf,0xbf239c9c,0x9cbf239c,0x9c9cbf23
+   .long 0x53a4a4f7,0xf753a4a4,0xa4f753a4,0xa4a4f753
+   .long 0xe4727296,0x96e47272,0x7296e472,0x727296e4
+   .long 0x9bc0c05b,0x5b9bc0c0,0xc05b9bc0,0xc0c05b9b
+   .long 0x75b7b7c2,0xc275b7b7,0xb7c275b7,0xb7b7c275
+   .long 0xe1fdfd1c,0x1ce1fdfd,0xfd1ce1fd,0xfdfd1ce1
+   .long 0x3d9393ae,0xae3d9393,0x93ae3d93,0x9393ae3d
+   .long 0x4c26266a,0x6a4c2626,0x266a4c26,0x26266a4c
+   .long 0x6c36365a,0x5a6c3636,0x365a6c36,0x36365a6c
+   .long 0x7e3f3f41,0x417e3f3f,0x3f417e3f,0x3f3f417e
+   .long 0xf5f7f702,0x02f5f7f7,0xf702f5f7,0xf7f702f5
+   .long 0x834f,0x4f83,0xcc4f83cc,0x4f83
+   .long 0x6834345c,0x5c683434,0x345c6834,0x34345c68
+   .long 0x51a5a5f4,0xf451a5a5,0xa5f451a5,0xa5a5f451
+   .long 0xd1e5e534,0x34d1e5e5,0xe534d1e5,0xe5e534d1
+   .long 0xf9f1f108,0x08f9f1f1,0xf108f9f1,0xf1f108f9
+   .long 0xe2717193,0x93e27171,0x7193e271,0x717193e2
+   .long 0xabd8d873,0x73abd8d8,0xd873abd8,0xd8d873ab
+   .long 0x62313153,0x53623131,0x31536231,0x31315362
+   .long 0x2a15153f,0x3f2a1515,0x153f2a15,0x15153f2a
+   .long 0x0804040c,0x0c080404,0x040c0804,0x04040c08
+   .long 0x95c7c752,0x5295c7c7,0xc75295c7,0xc7c75295
+   .long 0x46232365,0x65462323,0x23654623,0x23236546
+   .long 0x9dc3c35e,0x5e9dc3c3,0xc35e9dc3,0xc3c35e9d
+   .long 0x30181828,0x28301818,0x18283018,0x18182830
+   .long 0x379696a1,0xa1379696,0x96a13796,0x9696a137
+   .long 0x0a05050f,0x0f0a0505,0x050f0a05,0x05050f0a
+   .long 0x2f9a9ab5,0xb52f9a9a,0x9ab52f9a,0x9a9ab52f
+   .long 0x0e070709,0x090e0707,0x07090e07,0x0707090e
+   .long 0x24121236,0x36241212,0x12362412,0x12123624
+   .long 0x1b80809b,0x9b1b8080,0x809b1b80,0x80809b1b
+   .long 0xdfe2e23d,0x3ddfe2e2,0xe23ddfe2,0xe2e23ddf
+   .long 0xcdebeb26,0x26cdebeb,0xeb26cdeb,0xebeb26cd
+   .long 0x4e272769,0x694e2727,0x27694e27,0x2727694e
+   .long 0x7fb2b2cd,0xcd7fb2b2,0xb2cd7fb2,0xb2b2cd7f
+   .long 0xea75759f,0x9fea7575,0x759fea75,0x75759fea
+   .long 0x1209091b,0x1b120909,0x091b1209,0x09091b12
+   .long 0x1d83839e

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

2015-02-16 Thread Segher Boessenkool
On Mon, Feb 16, 2015 at 02:19:50PM +, 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?


Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev