The only functional part is ecb-aes in encryption mode. The decryption seems to work in 16 byte key mode. According to the spec [1] the decryption key is different and has to be computed by the HW. Chapter 11.1.4 says, that the decryption key is computed by performing a dummy encrypt operation. This does not alter my key at all. Point 1 on the next side is referring to the AesKeyRdMode bit which must be set prior reading the key. I can't find a definition of this bit so I guess the spec is out of date here. [Ronen Shitrit] you are right, this should be fix accordingly:
" To decrypt a data block with a given key, the host must first load this key into the decryption engine, then start the key generation process setting <AesDecMakeKey> field in the AES Decryption Command Register bit to 1. At the end of the key generation process, the host reads the key registers from the Encryption engine. This decryption key is loaded by the host into the decryption key registers, to start the required description process. To read the decryption key from the encryption engine, the host must set the <AesDecKeyReady> field in the AES Decryption Command Register to 1 prior to the reading of the AES encryption key registers. Setting this bit enables reading of the internal key in the AES Encryption engine, which at the end of an encryption process, is the key for the decryption start point." However a SW calculation is also possible. Chapter 11.1.4 in [1] says, that the decrypt key is the last 16/24/32 bytes created by the expansion algorithm. So I picked the key expand routine from generic aes module and just passed the crypto test for decryption with a 16 byte long key. The other two key sizes failed. Probably the the key slots are different. Currently I have no idea what's wrong. [Ronen Shitrit] on our driver we also chose the SW calculation WA, I'm not sure why your code fail, but I can refer you to our driver as a reference, maybe you can find it as a good reference also for other issues. This is an old LSP for the 5182, but the crypto driver supposed to work on the 5182 just fine: http://downloads.buffalo.nas-central.org/KBPro_ARM9/GPL/source/linux-2.6.12_lsp.1.10.3.src.tar.gz Look for aesMakeKey API under arch/arm/mach-mv88fxx81/Soc/cesa/ I also wanted to point that the crypto engine on the 5182 passed 2 more evolutions after the 5182, which included: - Add a dedicated DMA to the crypto unit. - Support only one channel. - Fix main erratas. - Decrease SRAM size to 2K. - Add support for chain mode. Maybe you should take those into account in your design to allow support for other crypto versions in the future. If you need more details pls check the security chapter on: http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F6180_9x_6281_OpenSource.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
