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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
