I designed this add-on library (LibLoad compatible) to fulfill any need for cryptography that may arise.
The library has 5 cryptographic-ish functions:

hashlib_Checksum24()
hashlib_Checksum32()
hashlib_CRC32()
hashlib_SHA1()
hashlib_SHA256()

The first two are generic additive checksums, the first being 24 bit and the second being 32 bit.
The third is the same CRC algorithm I used in Blast, and used to use in VAPOR.
The last two are SHA1 and SHA256. I tested them against multiple programs and input strings and thus far they appear to be bug-less, but I suppose that merely means I didn't try hard enough.
PS: I wrote this in C, then poked through the asm and converted the syntax as needed for the toolchain.
Thanks to beckadamtheinventor for some asm magic to help me do some psuedo-64-bit enumeration as needed for the bitwidth fields.
Thanks for commandz for walking me through the process for compatibility with LibLoad.

Edit: I will post a link once it gets approved to cemetech archives
This kind of contradicts many cryptography libraries out there which allow you to pass chunks of data as it is streamed across. But neat Smile
MateoConLechuga wrote:
This kind of contradicts many cryptography libraries out there which allow you to pass chunks of data as it is streamed across. But neat Smile

I could support that by exposing the underlying functions, such as sha*_update.
The hash isn't actually rendered until you call sha*_final, so presumably if I allow the users to call those particular functions, it would be more portable. Perhaps I'll do that.
This seem very reasonable as more programs start to implement USB Serial and internet libraries privacy and encryption will be needed. Great Idea Razz
File has been submitted to the archives.

I have gone ahead and exposed the backend routines that the main ones use to compile the SHA*

They are as follows:
hashlib_sha1init
hashlib_sha1update
hashlib_sha1final

The init function takes a SHA-1 context structure as an argument and initializes it to appropriate starting values.
Init must always be called if you plan to use the other two, but if you use the main SHA1 function, it is done for you.
The update function takes the context, the segment size, and length, and updates the context.
The final function takes the context and a digest buffer and generates the hash.

The SHA256 function has a similar group of backend functions also exposed.
hashlib_sha256init
hashlib_sha256update
hashlib_sha256final

They do the same as their SHA1 counterparts.

Edit: for the record, i snagged an open-source implementation of the SHA routines and modified them to work on the CE. Sadly, to not break the hashes, much of the values needed to be uint32, and for the bit-width, I enlisted beck's help devising a psuedo 'uint64_t` implementation.

And then I spent 3 hours trying to figure out why the SHA256 was not coming out right, only to realize, 3 hours later that the routine used variables that were defined in TI's headers as tokens. 3 hours wasted... for a simple fix. Sigh.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement