Author Topic: HASHLIB - A Cryptography Library for the TI-84+ CE  (Read 2101 times)

0 Members and 1 Guest are viewing this topic.

Offline ACagliano

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 919
  • Rating: +32/-2
    • View Profile
    • ClrHome Productions
HASHLIB - A Cryptography Library for the TI-84+ CE
« on: October 22, 2021, 09:50:28 pm »
yes, I post this on all three main forums

HASHLIB is a Libload-compatible library, I designed for use with the CE C toolchain [toolchain by MateoC (and others)]. It provides a fully-functional API for communicating securely with a remote host using NIST-standard encryption.

HASHLIB provides the following:
  • A secure PRNG that produces ~96 bits of entropy per 32-bit integer generated and passes all Dieharders regardless of sample size.
  • The SHA-256 cryptographic hash, as well as CBC-MAC authentication tags.
  • An implementation of Advanced Encryption Standard (AES), for 128, 192, and 256 bit keys.
  • An encrypt-only implementation of RSA for modulus size 1024<=modulus<=2048.
  • Implementations of PKCS padding schemes for RSA and AES
  • An implementation of SSL digital signature verification using RSA with SHA-256.
  • A buffer comparison function resistant to timing attacks.

Special thanks to beckadamtheinventor for help with SHA-256, jacobly for help debugging the SPRNG and writing the modular exponentiation function for RSA, and to Zeroko for walking me through generating entropy on a calculator.

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

Offline ACagliano

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 919
  • Rating: +32/-2
    • View Profile
    • ClrHome Productions
Re: HASHLIB - A Cryptography Library for the TI-84+ CE
« Reply #1 on: July 26, 2022, 09:47:11 pm »

HASHLIB is now on version 9.1, which brings the following feature additions and changes:

(1) CBC-MAC is removed
(2) An implementation of sha256-hmac is added
(3) PBKDF2 is implemented
(4) The API for hashes is revised. sha256_init/update/final have been replaced with hash_init/update/final and the init function takes an algorithm specifier. For example, `hash_init(&sha_ctx, SHA256);`. Once this is done, you can simply call hash_update/final on the context struct itself and the caller knows which algorithm to pass to.
(5) The entire function set has been changed for more clarity. Yes, it's nice to have functions inside of a library identify the library they are from (ie: hashlib_Function) but I decided the new function nomenclature is more clear:
Code: [Select]
// HWRNG (pools entropy from bus noise to sufficient entropy for a u32 per u32 returned)
csrand_init(), csrand_get(), csrand_fill()

// hashing
hash_init(), hash_update(), hash_final(), hash_mgf1()

// hmac
hmac_init(), hmac_update(), hmac_final(), hmac_pbkdf2()

// encryption
aes_init(), aes_encrypt(), aes_decrypt(), rsa_encrypt()

// misc
digest_tostring()          // convert a byte-digest to a hex string
digest_compare()        // timing-resistant buffer comparison

There is a compiler-time #define you can set if you are a more advanced user and want more backend access to the library functions. The flag is HASHLIB_ENABLE_ADVANCED_MODE. Those functions are:

Code: [Select]
// ECB mode is not cryptographically secure (many-time pad vulnerability), but blockwise ECB mode constructors can be built into more secure cipher modes.

// direct access to the OAEP v2.2 encoder for RSA

// direct access to the PSS v1.5 encoder for digital signatures. This was added for working with SSL certificates but that was removed from the library when I decided that functionality was beyond the scope of the library. I felt like it would be more apt that an SSL library layer on top of HASHLIB rather than be built into it. HASHLIB is an encryption/hashing lib, not a protocol lib.

// direct access to the modular exponentiation function hashlib uses, written by jacobly.

In addition to this API change, HASHLIB also implemented two new internal features meant to provide some resistance to side-channel attack. Granted, that is hard on a calculator because the platform isn't really designed to resist that type of attack to begin with and you can only do so much in algorithm design, but the following steps help.
NOTE: When using the extra functions in advanced mode, there is no guarantee those functions implement the following security mechanisms. Be aware of this when implementing.

(1) Purge of the stack frame before returning control from any function that places intermediary encryption data on the stack.

(2) Temporary disable of system interrupts while performing sensitive computations such as hashing, encryption, and more. This serves to resist attempts to map the device memory via any connectivity system that uses system interrupt to operate. Interrupt status is saved, interrupts are disabled, then the interrupt status is restored.
Code exists in many forms depending upon caller circumstance, but variations begin here:

Any tips or suggestions for additional security, comments, questions, or concerns welcome.