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

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

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)

Update

This morning, I was running some randomness tests on the outputs of the CSPRNG I wrote for HASHLIB, on the output from CEmu, my Revision A and N calculators, and am still waiting on Revision L output from beck to test. I'll edit this post with more data when I receive it, but here's the tests so far. Apparently, not *perfect*, but pretty good.

FOR CEmu

Code:


FOR REV-A

Code:


FOR REV-L

Code:


FOR REV-N

Code:

Ok, I need some assistance. This is crashing, and for the life of me I cannot figure out why.
Firstly, the source in C:


Code:


Secondly, a link to the ASM code this compiles to:
https://github.com/acagliano/hashlib-ce/blob/rsa/src/hashlib.asm#L6767

On line 7007, the `ret` instruction causes the code to return to 0xCFEB8D, rather than the place in memory the function was called from.
This triggers a

Code:

on CEmu, and crashes. I have zero clue why and how this is erroring in this way? Clearly the stack is garbled by something in this function, since the ret isn't going to the right place, but given this is compiled, I have no idea how this could be the case.


[EDIT] This crash is now resolved. The hash returned is still incorrect however.

UPDATE

A new version (v2) is out. https://www.cemetech.net/downloads/files/2123/x2373
This version sports the removal of the non-cryptographic hashes (checksum/CRC-32). It has the CSPRNG added, derived from data compiled in this topic. It also adds Blowfish encryption, Base64 encode/decode, and there are plans to add the encryption side of RSA as well, for variable key sizes between 512 and 1024 bits. I also included a whitepaper in the download, to present sourcing information, info about about algorithms I wrote myself, and credit people. Much thanks to Zeroko for information on randomness, and to beck and command for assistance with some C to Asm conversion of parts. The algorithms still are a tad slow, so bear with me. Optimizations will come at a later date, in v3 most likely.

UPDATE

Archives Download: https://www.cemetech.net/downloads/files/2123/x2386
Github: https://github.com/acagliano/hashlib/tree/stable

The repository is now set up such that cloning the project gives you the built library, documentation, PRNG statistics, and the .h and .lib files, but that moving to the `dev` branch gives you the C codebase. They are distinct because the compiled C undergoes significant manual tinkering before being built into the library.

This update of HASHLIB adds AES-128, AES-192, and AES-256 support. Believe it or not, the AES implementation is faster than Blowfish. The cipher uses Cipher Block Chaining mode. This means it takes a key of 128, 192, or 256 bits in size as well as an initialization vector that is a pseudorandom 16-byte string.

In addition, I have also added a padding scheme implementation function. You pass it your plaintext and PT size, as well as constants indicating the algorithm to pad for (Blowfish/AES) and the padding spec to use. The available options are:

Code:

UPDATE

New release available, however, this one I will not be uploading to the archives...the next one to upload will be the fully complete one. This download (v4) will be available from the github:

https://github.com/acagliano/hashlib/releases/latest

What's New, v4

1. AES-CBC-MAC.
A modification of the AES-CBC cipher mode that produces a MAC tag one block long, rather than an output ciphertext. This one does not take an IV, but requires a unique key schedule.

2. Added a helper function macro that takes the plaintext, an output buffer, two unique key schedules, a padding scheme spec, and a random IV, and outputs a message according to the following IPsec-derived standard:
a) AES-CBC encrypt the plaintext over k1 and the random IV.
b) Output the random IV followed by the ciphertext to the output buffer.
c) Pass the output buffer to the AES-CBC-MAC function for a constant IV and k2.
d) Output the MAC to the end of the output buffer.
The resulting output should be resistant to CCA.

3. A function that takes a ciphertext and some k2 (ks_mac) and attempts to validate the MAC of that ciphertext.

4. A buffer comparison function that is resistant to timing attacks by always comparing the entire buffer, regardless of whether (or if) some position in the comparison doesn't match. EDIT: jacobly supplied a new function in asm that actually IS resistant to this attack, mine written in compiled C apparently wasn't.

Me and Cags have been scratching our heads trying to figure out why the SHA256 functions in the assembly rewrite of hashlib are producing incorrect hashes. If someone would be willing to help us figure out what's going wrong or what area isn't being initialized correctly or at all that would be much appreciated
https://github.com/acagliano/hashlib/tree/sha256-asm

Specifically this file: src/asm/sha256.asm

Ok, after much debugging pain, we have made some headway debugging the SHA routine. It now works for data less than 56 bytes in size (such that the hash only processes one block). However, beyond that, it still outputs the wrong hash. We have been working out brains last night and pretty much all morning/afternoon to fix both the initial bug and this one, but are thus far unable to trace the current bug for data lengths more than 1 block. We will keep at if, but if anyone wants to review the code and point out anything, feel free.

I personally suspect something in the initial logic of the Final function, or a segment of the update loop. Here is the link to the code, and the associated, working, C code.

Possibly bugged section of SHA_Update()
https://github.com/acagliano/hashlib/blob/sha256-asm/src/asm/sha256.asm#L91

Associated C:

Code:



Possibly bugged SHA_Final()
https://github.com/acagliano/hashlib/blob/sha256-asm/src/asm/sha256.asm#L114

Associated C:

Code:


I prefer the former as the source of the bug (the Update function) (I may, and likely am wrong, however) because the file we are hashing to test has a remainder block size less than 56, meaning the logic that would run in SHA_Final would be the same logic as what runs for a single block of data, which is returning the correct result. Thus I suspect a bug in the Update function. I suspect there is no bug in the transform function anymore because getting a 1-block correct hash rules that out.

Hashlib sha256 hashing assembly rewrite has been completed!
Takes ~1.577 seconds to hash the entirety of the latest GRAPHX!

The Time Has Come!! for another progress update.

HASHLIB v6 is out on Github: https://github.com/acagliano/hashlib/releases/latest

Here's What's New:
(1) MGF1 hashing function is added. It uses SHA-256 and hashes a given length of data as well as a 4-byte counter.
(2) OAEP now uses MGF1 (as is standard) instead of cyclic SHA-256.
(3) SPRNG now minimizes entropy loss due to correlation (thanks, Zeroko!) and runs ~1.5x faster for generating large pools of random data. The entropy pool is reduced from 192 bytes to 119 bytes, but each time we update a byte in the pool from the entropy source, it is a composite of 7 distinct reads xor'd together.
(4) SPRNGRandom() rewritten in assembly. Thanks to jacobly for optimization and some small code corrections.
(5) SPRNG now uses FastMem for its SHA memory and entropy pool to accelerate even faster.
(6) AES ECB-mode single block encrypt/decrypt functions exposed to let skilled users construct their own cipher modes
Still waiting on vint powmod to be fixed in the bigintce library, and then RSA will be added for v7.

Another Update/Improvement

This update is not yet a release package, however, it can be downloaded from the stable branch of the github.

The RSA-OAEP encoding scheme has been updated from the PKCS#1 v1 standard to the one outlined in PKCS#1 v2. Have a look at this for details: https://datatracker.ietf.org/doc/html/rfc8017#section-7.1

The RSA-PSS encoding scheme is implemented as well for working with SSL-RSA signatures.
Sadly however, I am having difficulty testing these because from what I can tell, the libraries hide the underlying aspects of these schemes well. They seem to want you to pass padding and algorithm specs to a signature/encryption function rather than call the padding functions explicitly (which is fine, but RSA itself isn't actually implemented in hashlib yet, so, not really). If someone knows a way I can do this anyway, feel free to comment.

I also want to implement ECDSA signature verification, but as I know very little about elliptic curves and less about how ECDSA itself functions, it will likely be some time, if I do it at all. I have been referencing this: https://www.instructables.com/Understanding-how-ECDSA-protects-your-data/ as well as the wiki, but this stuff is not easy to understand (at least for me). If someone here has a reference for a more broken down tutorial, or even some code samples, feel free to share, and thanks in advance.

Update HASHLIB moves into RC-1

With all the thanks in the world to jacobly for the modular exponentiation function we needed for RSA, HASHLIB is now formally complete (apart from the possibility of adding ECDSA in the distant future) and will soon be released on github for testing.

As many of you may know and others will learn by reading this, HASHLIB contains the following crytographic implementations:

<> A secure PRNG that produces ~96 bits of entropy per 32-bit integer generated.
<> The SHA-256 cryptographic hash.
<> An implementation of Advanced Encryption Standard (AES), for 128, 192, and 256 bit keys.
<> An implementation of RSA encryption up to 2048 bits in key length.
<> An implementation of the appropriate padding schemes for the above encryptions.
<> An implementation of SSL signature verification using the RSA with SHA-256 signing algorithm.

Feel free to download and test against commonly used cryptography libraries and report back on compatibility or lack thereof.

https://github.com/acagliano/hashlib/releases/tag/v7-RC1

HASHLIB moves into v7.1-rc1

After thinking a bit about how some of the API is laid out (namely requiring users to pad the plaintext prior to passing it to the encryption algorithms), I decided to internalize that functionality. You still have access to the padding functions but those are only for if you need to pad something without encryption. Now, whenever you encrypt with AES or RSA, the padding scheme is applied automatically. For RSA, this is OAEP v2.2. For AES, this can be either PKCS#7 (default) or ISO-9797 M2.

This being said, I have a small request for those in the Cemetech community who may be knowledgeable on the field of crypto. I'd like to put together a cryptanalysis of HASHLIB without the biases of reviewing it myself. The repository that some of the code is sourced from is linked in HASHLIB's github, and the code is available for review there. It's important to note that some of it was written in pure assembly (SHA-256, powmod, and the SPRNG), while other parts (the AES functions and the RSA wrapper functions) were written in C.
https://github.com/acagliano/hashlib
I am aware the library likely offers no side channel resistance, but I am curious what sort of resistance it offers to other forms of "breaking" and if anyone has suggestions for improvement.

HASHLIB v8.0-rc1 update


Version 8 brings 2 new algorithms and significant security enhancements.
The HMAC variant of SHA-256 is implemented, allowing users to use hashes that integrate a key into the initial state.
The PBKDF2-HMAC algorithm is implemented, allowing users to generate a key from a password.

To protect against buffer leak, all user-facing functions erase the contents of the stack frame before returning. To protect against an adverse user mapping the memory or variables on the device while HASHLIB is doing its thing, we disable system interrupts during user-facing functions.

Here's the latest release for testing. Let me know if there are any issues.
https://github.com/acagliano/hashlib/releases/tag/v8-rc1
I'll move the release to stable if there are no issues reported after some time.