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

Reply via email to