HASH: mixed feeding it with DMA and non-DMA writes possible?

[our]

Posted on October 31, 2015 at 15:55

When I feed HASH with regular writes only or DMA only, everything is OK.

But I need to use both methods when computing hash of a long message, and in this case I cannot manage to compute right hash value.

Did anybody tried this?

[Tesla DeLorean]

Posted on October 31, 2015 at 22:06

All the data goes through the same register, you will have to be very careful managing the ownership of the resource. Consider moving data manually in the DMA TC interrupt, or immediately prior to enabling the DMA transfer for the bulk of the data.

Perhaps a semaphore/mutex?

[our]

Posted on November 02, 2015 at 14:20

I reduced the case to the following very simple one:

Computing SHA-256 of the message of 1 million 0x61 bytes (character ''a''), as in FIPS186-2 example.

If I send data by 15625 blocks of 64 bytes with DMA, and clear HASH_CR_MDMAT bit before the last block,

I can then simply read the right digest:

while (HASH->SR & HASH_SR_BUSY) __DSB ();

digest[0] = (HASH_DIGEST->HR)[0];

...

digest[7] = (HASH_DIGEST->HR)[7];

Digest is

CDC76E5C9914FB9281A1C7E284D73E67F1809A48A497200E046D39CCC7112CD0

Surprisingly, it matches with FIPS example! :-)))

But I can also do slightly differently:

Send all 15625 blocks of 64 bytes with DMA, without clearing HASH_CR_MDMAT.

Then I can set HASH_STR_DCAL bit manually, can't I?

HASH->STR = HASH_STR_DCAL;

And I expect to have the same digest.

But in fact I have

A2009D7FEF3593E39A4F69F25F0D7ADA9A1E40161551675E8D96E98956ED111D

What is wrong?

[Tesla DeLorean]

Posted on November 02, 2015 at 14:54

Can you post a complete/concise example demonstrating the failure?

Stating the exact part you're using might also be helpful.

[our]

Posted on November 02, 2015 at 16:38

This is it (please find IAR project attached).

Part is STM32F439IIH.

________________

Attachments :

hash_test.rar : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I19R&d=%2Fa%2F0X0000000bjQ%2FDHSMxcAUKOnzsdNnEEcbmGpz91mdq6ygW6roTqyFyus&asPdf=false

[Magnus Berg]

Posted on June 18, 2017 at 17:51

No reply on this one? I noticed the same thing in our STM32F439 when I tried the other day.

I'd like to add a similar question. I'm getting some odd length msgs in my HASH calculations, so I tried to use a byte sized memory access to fill the FIFO, and then use Word sized write to the HASH DIN register. But when I try that, I get the incorrect digest. Also, if I read the HASH DIN register after the transfer is completed, it returns 0, which is not the last 4 bytes.

However, if I instead use the FIFO, but use Word sized access to read it from memory, everything works as expected. I get the correct digest and I see the correct last 4 bytes in the HASH DIN register afterwards.

As it stands, I'll probably need to handle the byte skewing myself and write to HASH DIN manually, but I'd much rather use DMA of course.

[Tesla DeLorean]

Posted on June 18, 2017 at 20:49

The subset of users with HASH/CRYPT parts is quite small, and those using them professionally probably have reasons not to talk freely..

I'd suggest you not only look at the length, but the alignment of the memory buffer.

[Magnus Berg]

Posted on June 19, 2017 at 07:52

Hi

Alignment is not the problem. The testbuffer is aligned on a 4-byte boundary and I can hash it using memory Word reads (via FIFO) which generates the correct digest. But when hashing the same data with Byte reads via FIFO, it's wrong.

The only lead I've seen is that the DIN register is 0 after such an incorrect hash operation (instead of the last 4 bytes as it should), but I'm not sure where that leads me.