* Ronen Shitrit | 2009-03-04 18:05:12 [+0200]: >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/ Oh thanks a lot. I take a look on this. >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. Does this mean that the crypto unit itself is now able to copy data and I don't have to use the idma for that? That sounds great. >- Support only one channel. >- Fix main erratas. >- Decrease SRAM size to 2K. >- Add support for chain mode. I can understand that, since SRAM is not that cheap and with chaining support it should not matter. >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 I take a look on this as well. Sebastian -- 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
