PIC18 SHA1/MD5 Performance and Internal Flash Storage

This is my fifth week of intern in AESTE. Continuing with synchronizing SHA1 for CLIENT and SERVER also added HMAC-MD5 into my project. The code to generate a HMAC-MD5 is exactly the same with the code I written for HMAC-SHA1 just slight different in the Hash function used (which is based on HASHES.c from TCPIP Stack provided by Microchip). After having both MD5 and SHA1 capable of producing HOTP value, I did some performance test for this 2 hashes, the following table describe the result I obtain.

From the result, it is pretty clear that MD5 is slightly faster than SHA1 due to the number of digest data it produces, but MD5 is less secured compare to SHA1 because of the digest data is shorter. Therefore it depends on the application requirement to decide which hashes meets the application requirement. For a more secured hash function but more computation power required are SHA2 and SHA3. Which a PIC18 is not capable of producing.

Speaking of synchronization method, the HOTP that I implemented is a counter based, every single time a CLIENT send a request with a HOTP value, the SERVER will increase its counter to generate HOTP and compare with CLIENT. When a HOTP matches, the current counter value will be stored in the SERVER. However let’s say for instance the CLIENT accidentally generated extra HOTP (increasing CLIENT counter), SERVER will try to increase its counter step by step till 5 iteration maximum to match with the HOTP from CLIENT.

All these Counter and Key for HMAC-SHA1/MD5 are stored in the internal flash of PIC18. This is for back up purposes in case a power failure occur, causing PIC18 to restart, resulting the Counter to goes back to zero which is not ideal at all. To store data into internal flash of PIC18 follow this document AN1095. The method from the document is called Data Emulation, whereby rather than throwing a huge chunk of data into internal flash, this Data Emulation method will store WORD of data (8bit for PIC18) in a very efficient way.

Beginner Guide to use AN1095 in PIC18:

1. Read the document alphabetF by alphabet
2. Include all the FILES (.c .h .asm and .inc) into own project
3. Change the #include in example code to match the one in own project
4. A friendly reminder: MPLABX -> Windows -> Program Memory -> Memory will not show the data stored eg: 0x10, but only 0xFF will be given, however by using ‘DataEEWrite’ from AN1095, the particular data (0x10) will definitely be stored in the internal flash just cannot be shown using MPLABX
5. Use the function ‘GetNextAvailCount(bank)’  bank = 0 or 1 for PIC18 to check the ‘page’ size, by default if GetNextAvailCount(0) >= 64 it means that the page is already full
6. From AN1095 it stated that it will auto pack the page or i should say filter the data properly once the page is full (GetNextAvailCount(0) >= 64), however I realized it never once auto pack the data. Therefore the data must be manually pack to allow more data to be stored into internal flash
7. To do so just use the function ‘PackEE(0 or 1)’ and continue with DataEEWrite/Read
8. It is just that simple, and for PackEE function the whole PIC18 operation will halt for a few seconds to perform the filtering.

After ensuring the HOTP for PIC18 works properly I proceed with creating a self generated HOTP for Client using Wt C++ web toolkit. Looking forward to next week with more C++ programming, less C code programming and more hair lose =/