Video Demos
May Update! Project is finished! Working on finals now, and then this section will be finished. But a video is ready.
Github: https://github.com/NiantongDong/Digital_Wallet
Work in progress section for a semester project for BU EC 544: Networking the Physical World during the Spring 2021 semester.
The general goal was to make a full cryptography stack mimicking functionality of a bitcoin/cryptocurrency wallet.
More to come soon after the project is fully finished, but I wanted to write a little bit after making some very solid work on the hashing and encryption side of the project last night (while my neighbours were keeping me awake with a party until 4:00 am).
This entire project has been a deep delve into complicated library documentation and reference guides. Wow, I’ve never had to scan through this many technical documents nor learn about such a complicated IDE. MCUXpresso is an amazing tool I hope to learn more about someday soon.
For now though, I’d like to describe some troubleshooting that arose while trying to print my output string while trying to sign a message. Becuase the starting public and private keys were generated with the RSA2048 standard, with fixed lengths of 256 bytes. If one were to do strlen(signed_message) they would then expect return 256 bytes. This was not the case, and it was returning 186 bytes. If you immediately know what we were doing wrong, kudos to you. But figuring out why took a considerable amount of time (around 8 days). The key was considering what the output of the encrypted message actually looked like on a bit-level.
The goal of the encryption is to hide some message behind a lock. Altering the message on the bit level seems like one of the most secure approaches, as the bits are the smallest layer we can change. Because of the functions we used (mbedtls) we had to still handle these messages as char*. This data type lets us use some fun tools, like sizeof() to tell us either the number of bytes of each array element if the char* is dynamically allocated (malloc, calloc). What’s interesting about sizeof() is that on statically linked arrays, like MyArray[2048], sizeof(MyArray) will tell us the entire length of the array. Cool.
So sizeof(signed_message) was 186, but we also knew that 256 total bytes were actually written into the string, but for some reason weren’t accessible. A printf(“%s”,signed_message) would truncate the string. We knew the signing had worked, as an online comparison showed the first 186 characters were identical. If there had been any downstream issues, our signing would be very different given the hashed nature of our input message. So we knew we had a buffer issue where we weren’t able to empty the entire contents of the file. Why?
![If we inspect sign[], our signed hashed value, it does have 256 elements and they seem to line up. But its only printing 186 of them. This tool is one of my favourite things about MCUXpresso thus far. I had to insert a breakpoint at the start of my …](https://images.squarespace-cdn.com/content/v1/60243f3451c2e8446b9ec8a0/1618683351178-6LJ9X2F5ZKMOUSRYZOWK/code1.png)
If we inspect sign[], our signed hashed value, it does have 256 elements and they seem to line up. But its only printing 186 of them. This tool is one of my favourite things about MCUXpresso thus far. I had to insert a breakpoint at the start of my exit condition, but that’s normal troubleshooting. Hovering over a variable during runtime while paused at a breakpoint lets me inspect actual values in real-time, helping me validate the size of my signed message, and confirming it was the same as the web-calculated version.
Oh well would you look at what we find right after our "îNX" in the raw string, a "\0". And it just so happens to be element 186, exactly where a strlen() function may return(). That would definitely be our issue. The string is seeing that and terminating before it can finish, since that's the end of file operator. Because we are recasting this signed message as char*, the string functions we are using read the 00000000 as ASCII Null, which terminates the string function by design. Remember the signed message is just some encrypted value, not representative of any actual characters. It has to be decoded first, otherwise its meaningless junk.
By changing the length arguments used in our mbedtls functions, and implementing different print methods for the encrypted base64 messages (used to make the signed messages human-readable) we were able to print the expected results, sans truncation.
