2016-10-13 03:41 PM
Dear All,
I successfully could integrate the AES GCM algorithms (firmware variant, no hardware acceleration) of STM32 cryptographic library v2.0.6 into the project. It encrypts and decrypts the plaintext correctly without any error. Simultaneously, there is another crypto project in the PC side using the Crypto++ library with the same AES GCM encrypt/decrypt parts. Here, too, everything works. However, the problem is that when using the same AES256 key, IV array (size 12), plaintext, header (AAD), the STM32F4 and the PC generates different ciphers and tags. Their lengths are the same across the platforms but the content is totally different. So it becomes impossible to encrypt in PC and try to decrypt the cipher in STM32F4. I have tried to supply the cipher and the tag generated in STM32F4 to the PC decrypted but it breaks with the error:Caught HashVerificationFailed...HashVerificationFilter: message hash or MAC not valid
So my question what might be the problem that they generate different ciphers? Thanks a lot for any suggestion. #!stm32 #help-thyself
2016-10-19 09:08 AM
Dear Clive,
Thank you for your suggestions. Tha part is STM32F415VGT6. Code program itself is very simple and seems to work. In the main function the above written test_enc_dec is called afterwards an infinite led blinking is starting. So I can see the led blinking so the clocks should be fine (I used this part extensively in other programs without crypto lib). Could you please tell how should I handle CRC prior to calling the crypto functions? Do I need to do anything explicitely with CRC? I will try your other suggestions which hopefully will help. Thanks again.2016-10-19 09:28 AM
Dear Clive,
I am happy to say that after initializing the CRC with: RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_CRC, ENABLE); everything works correctly now. Thank you so much for your great help!2016-10-19 10:58 AM
The library authenticates itself as running on ST hardware (vs NXP, ATMEL, etc) by checking that it can use the CRC peripheral. It should enable it, but apparently doesn't. The SDIO/CRYPT units depend on a 48 MHz coming from the Q-Tap of the PLL. I've not double checked it for the CRYPT unit, but SDIO doesn't work if the PLL isn't running, ie straight from HSE or HSI
/* Enable CRC clock */ RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_CRC, ENABLE);2016-10-19 11:39 AM
Dear Clive,
Yes, your hint about the CRC solved the problem. Thank you very much for the additional information.