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.
I realize that I haven't shared much of an update on what's going on with this project lately so here it is.

beckadamtheinventor (bless his soul for the pain it's brought him lol) offered to do a rewrite of HASHLIB in assembly. The original was coded in C, based on B-Con's Crypto algorithms which is public domain. I modified the original code to be tailored to a 24-bit architecture, then compiled, formatted the assembly, and created the lib. I did this because my experience with assembly is practically non-existent. The downside was it was quite unoptimized.

For HASHLIB 2 (and later 3), the plan is to rewrite the routines in assembly, a process primarily being undertaken by BECK, with me performing some testing/debugging assistance. In addition we have plans to add another fun and proof-of-concept, but kind of useless feature to HASHLIB... RSA. The library will be able to generate RSA keys of 64-, 128-, or 256-bit length and use those keys to encrypt and decrypt data. It would do this by initializing a context, one for the private key (generated locally and used for encryption) and another for the public key (generated by some remote host and sent to the calculator, and used for decryption).

We did encounter a setback... the assembly SHA-1 algorithm was buggy and we still have not been able to resolve it. At first, I thought the issue may have been a SRLDRVCE bug since VAPOR crashed as soon as it tried to initiate a transfer. However, upon using the debugger, I realized that the crash occurred in the usb_handleEvents function after the first call to hashlib_sha1final. I also realized that the serial state was corrupt at this point and that the serial memory happened to be right after the sha1 output buffer in memory. This lead to the theory that sha1final was overflowing the digest buffer (the hash output was wrong as well which reenforced this theory) and corrupting the serial state which was after it. I passed this info to beck and command who eventually identified the culprit as sha1_update (or transform, not quite sure) in the assembly version. However, they were unable to figure out *why* the code was breaking.

On the topic of RSA, I have some questions regarding on-calc applications
What would be the fastest way to generate a prime number in a range?
Is Miller-Rabin the fastest primality test?
Would pairing calls to MR Primality test with calls to rand be the most effective implementation of a prime number generator?
Any assembly optimizations?
Update

No downloads yet, but I did complete the RSA algorithm in C.
It's a 64-bit implementation (each key is 64 bits long). Not cryptographically secure, I know, but this IS a calculator, and this is more a learning exercise for me.

The implementation can be found at: https://github.com/acagliano/hashlib-ce/blob/rsa/src/main.c#L404
Unlike some of the other things in the code here that are modified variants of public-domain algorithms, the code for the RSA bit I did myself (albeit relying on some pseudocode and algorithm explanations).

To sum:

# KeyGen #
<> Pick 2 random 16-bit primes, using randInt()
** If someone can suggest a randOddInt() implementation that would allow me to skip the first primality check (is odd?), I'll use it**
<> To verify primality:
<> check if divisible by 2
<> run 3 iterations of Miller-Rabin primality test. If all 3 return true, we accept the random prime
<> Calculate the key segments from the two primes
(Right now, I used 16-bit primes to stick within the uint32_t maximum integer range of the toolchain for each key segment. If support for larger numbers is added to either the toolchain or a library, I will adapt this code accordingly)
<> Used a modular exponentiation algorithm within Miller-Rabin as well as within Encrypt/Decrypt. (credit to beck for sending me info on that)
<> Used euclidean GCD algorithm for getting value of E (in keygen)
  
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