SHA256 RSA digest

[jim239955]

Posted on March 01, 2017 at 22:48

I have this working on a stmicroF427 part and I am trying to run the same code on a STmicroF103.  The only changes are that I used the M3 versions of the library on the F103 part, and the 427 system uses cube and the HAL libraries.  The code running on the 103 does not generate a correct digest.  I have verified that the data is good (there is a CRC also).  Can someone verify that this does work on the F103 part and that there are no setup steps that I may need to do to run this?

[waclawek.jan]

Posted on March 01, 2017 at 23:29

There's no HASH hardware in the 'STM32F427, so are you talking about some publicly available library?

JW

[Tesla DeLorean]

Posted on March 02, 2017 at 00:43

HAL Crypto Library by the sounds of it.

HW CRC needs to be enabled on other platforms.

[jim239955]

Posted on March 02, 2017 at 20:10

On the ST32F427 we used HAL libraries on the ST32F103 we did not.  Both projects use the STMicro Crypt library.  I can see on the ST32F427 (cube) that I am using a function (__CRC_CLK_ENABLE ();) that sets the clock bit in the AHB1ENR register: SET_BIT(RCC->AHB1ENR, RCC_AHB1ENR_CRCEN);  I naively thought I could just do:  RCC->AHBENR |= RCC_AHBENR_CRCEN;  but that doesn't seem to do the trick. 

[Tesla DeLorean]

Posted on March 02, 2017 at 21:42

On the F1 I seem to recall using M3_CryptoFW_2_0_6.lib in Keil

/* DeInitialize STM32 Cryptographic Library */

Crypto_DeInit();

** Section &sharp76 'i.Crypto_DeInit' (SHT_PROGBITS) [SHF_ALLOC + SHF_EXECINSTR]

Size : 8 bytes (alignment 2) Address: 0x00000000

$t

i.Crypto_DeInit Crypto_DeInit 0x00000000: 2101 .! MOVS r1,&sharp1 0x00000002: 2040 @ MOVS r0,&sharp0x40 0x00000004: f7ffbffe .... B.W RCC_AHBPeriphClockCmd

[jim239955]

Posted on March 02, 2017 at 22:23

>>On the F1 I seem to recall using M3_CryptoFW_2_0_6.lib in Keil

Yes that’s what I am using (IAR).   M4_ causes a hard fault.

>>/* DeInitialize STM32 Cryptographic Library */

>>Crypto_DeInit();

Yes I am doing Crypto_DeInit  I changed the clock enable to: RCC_AHBPeriphClockCmd(RCC_AHBPeriph_CRC, ENABLE);

Interestingly, Crypto_DeInit does seem to matter for the F427/HAL implementation.

I tried enabling CRC clock after this call.  No joy.

Not sure what the following tells me. 

>>** Section &sharp76 'i.Crypto_DeInit' (SHT_PROGBITS) [SHF_ALLOC + SHF_EXECINSTR]

>>Size : 8 bytes (alignment 2) >>Address: 0x00000000

>>$t

>>i.Crypto_DeInit >>Crypto_DeInit >>0x00000000: 2101 .! MOVS r1,&sharp1 >>0x00000002: 2040 @ MOVS r0,&sharp0x40 >>0x00000004: f7ffbffe .... B.W RCC_AHBPeriphClockCmd

[jim239955]

Posted on March 02, 2017 at 22:50

Is it possible that there is an upstream clock that needs to be set up?

[Tesla DeLorean]

Posted on March 02, 2017 at 23:06

It basically show that Crypto_DeInit is only turning on the CRC clock.

I'm not going to spend hours building a test fixture, if you have some test case code post it here, or to me privately. This will be a lot easier than guessing wtf is wrong.

[jim239955]

Posted on March 02, 2017 at 23:14

>> I'm not going to spend hours building a test fixture.

Oh gosh no, don't do that.

>>if you have some test case code post it here

I think my next steps are to reduce this to something really small to test my assumptions. If I get there I will post my code. It was useful to have someone let me know that basically my assumptions aren't completely in left field. thanks.

I am just moving back to low level embedded after a bunch of years. Your example code has been a big help!