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

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 offset=

s 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 0x6dbbbbd6,0xd66dbbbb,0xbbd66dbb,0xbbbbd66d
+	.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