* 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to