I am currently writing a linux (µcLinux) driver for the mmcau cryptographic unit present on my K61 device.
I have currently successfuly ported the AES, DES and MD5 functions using the cau_api.h and assembly file but I am running into some issues with the SHA1 function.
Basically, what I am doing is writing some binding code to replace the native crypto functions of linux with the ones accessing the mmcau unit.
For the moment, I validate the behavior with the internal tests run by linux when it loads the kernel driver accessing to the funcion (here SHA1) of the mmcau driver.
The code for the driver is in attachment (kinetis_mmcau_sha1.c)
Linux passes its first test (validating the hash for a message containing "abc"), but it crashes during the second message.
This second message is "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq".
What I can see is, for that test, two passes shall be done with the cau_sha1_update function.
- 1. Actual hash of the message + some part of the padding (only 64 bits out of the 512 which are necessary for the initial message length of 448 bits).
- 2. The rest of the padding + the 64 bits of the message length.
This is summarized in the attchment MMCAU_SHA1_Test2_Debug_info.txt.
Using a Python reference sofware, I could get access to the intermediate state value that I shall be producing after the 1st 512 bits block of data has been processed.
I can therefore see that this first pass is ok. (the output of the python script is attached for reference too: MMCAU_SHA1_Test2_pythonOutput.txt)
The main issue seems to be produced with the second pass (the reminder of the padding data + data length).
I tried several things (amongst which changing the endianess of the state values - since I got to do it in the end to present the data according to the big endian specification of SHA1 while the data produced by cau_sha1_update are little endian) but it does not solve the issue. Strangely enough though, when I do change the endianess of the state value, the result produced by cau_sha1_update is actually similar to the one without the change of endianess of the previous state variables, except for the endianess.
I have attached the output produced by the driver for both cases as an illustration.
I must confess the behavior is quite confusing and has been keeping me busy for quite a while now.
I would therefore appreciate if you could help me on this.
Original Attachment has been moved to: MMCAU_SHA1_Test2_driverDebugOut_OrigEndian.txt.zip
Original Attachment has been moved to: MMCAU_SHA1_Test2_pythonOuptut.txt.zip
Original Attachment has been moved to: MMCAU_SHA1_Test2_Debug_info.txt.zip
Original Attachment has been moved to: kinetis_mmcau_sha1.c.txt.zip
Original Attachment has been moved to: MMCAU_SHA1_Test2_driverDebugOut_ModEndian.txt.zip