sha256 and the cortex M4

[manitou]

I notice that the uhashlib uses crypto-algorithms/sha256.c to implement the hash. Has anyone looked at the Cortex M4 hash processor (chapter 25 ref manual) which provides a hardware implementation of sha256?

Looking at the firmware, there are already HAL routines for the hash and SHA256 (stm32f4xx_hal_hash_ex.c stm32f4xx_hal_hash.c).

[manitou]

Since the HAL abstraction was available for the SHA256, I hacked the firmware Makefile and some .h and .c files to enable the HAL SHA256 layer. I then added some timing and testing to the firmware to get C performance.
Doing a 1000 hashes of 1024-byte buffer in micropython on the pyboard (@168MHz) using uhashlib.sha256(), i measure 1379 KBs (1000 bytes/sec). Measuring the speed of the underlying C library (sha256_init() et al), i get 1950 KBs.

The ref. manual suggests the HASH hardware can do 64 bytes in 50 ticks (max rate about 214765 KBs). Deploying the HAL layer for the hash hardware, i get 62645 KBs. The rate seems to vary appropriately with different block size or repetitions, BUT at the moment the test vectors are returning 0s for the hash result from the HAL layer.... so I haven't quite figured out the HAL SHA256. here's the code I'm using in the firmware

Code: Select all

       HASH_HandleTypeDef h;
       memset(&h,0, sizeof(h)); 
       __HASH_CLK_ENABLE();
       h.Init.DataType = HASH_DATATYPE_8B;
       HAL_HASH_Init(&h);
       HAL_HASHEx_SHA256_Start(&h,buff,sizeof(buff),hash,HAL_MAX_DELAY);

while measuring in the firmware, I tested the rate of the of RNG (rng_get() 32-bit random number). I measured a rate of 36.5 mbs (megabits/sec). The hardware spec is 32-bits per 40 ticks of the 48mhz clock, or about 38.4 mbs. For pyb.rng(), i measure a rate of 1.9 mbs. I also collected 1 megabyte of random data from pyb.rng, test with randomness with various tools, and unsurprisingly pyb.rng() (and the underlying hardware RNG) is producing good random data.

[Damien]

Note that the STM32F405 (the MCU on the pyboard) does not include the hash processor. You need the (more expensive) STM32F415. So that's why you are getting all 0's returned.

[manitou]

Well, duh. that explains why STM "forgot" to list the HASH peripheral boundary address in table 10 of the datasheet. (I didn't let that stop me obviously) DANG

thanks