Hashlib's API is getting a bit of a facelift. No massive functional changes, just an API that is a bit more clear and concise and has less fluff (and less exposed functions).
The new API have a class-esque appearance with subclasses delimited by underscores, like so:


// Secure RNG functions

// Hash functions

// HMAC functions

// Cipher functions

// Digest functions

It's my hope that the new nomenclature of the functions improves usability as well as the portability of adding new functions to the library.
AES ECB block encryptors and padding functions are no longer exposed given that the exposed cipher methods automatically apply and strip padding, ECB mode is insecure and lacks the side channel resistance measures placed in the exposed methods.

With that out of the way, great progress.
Also I think if you're already copying the function entry points into the hash structure you should expose the routines as part of the struct rather than exposing routines to call those routines.
beckadamtheinventor wrote:
Also I think if you're already copying the function entry points into the hash structure you should expose the routines as part of the struct rather than exposing routines to call those routines.

Well, I actually defined the pointers in the structs as the proper types:


typedef struct _hmac_ctx {
    bool (*init)(void* ctx, const void* key, size_t keylen); 
    void (*update)(void* ctx, const void* data, size_t len);   
    void (*final)(void* ctx, void* output);                 
    union _hmac {           /**< a union of computational states for various hashes */
        sha256hmac_ctx sha256hmac;
    } Hmac;
} hmac_ctx;

So the user is at perfect liberty to use a more procedural format or a more OOP-esque format.


hash_ctx ctx;
if(!hash_init(&ctx, SHA256)) return 1;

// Method 1 (Procedural)
hash_update(&ctx, data, len);
hash_final(&ctx, digest);

// Method 2 (OOP-esque)
ctx.update(&ctx.Hash, data, len);
ctx.final(&ctx.Hash, digest);
// ctx->update/ctx->final if a pointer.

The new update will be out later tonight, or tomorrow, the latest.
If anyone has code for other crypto hash algorithms besides SHA256, feel free to contribute them and I'll add them to the lib.
"Tonight or tomorrow, the latest", he says. Sure thing.
In my defense, I had some difficulty ironing out some bugs.

Update 9.2

AES implementation is reworked. Uses a stateful context that is stream-safe. This does require a user to open two contexts if they need to communicate in both directions. You can also configure the cipher in the init function rather than init'ing it and then editing the fields you want to change.:


aes_ctx ctx;
uint8_t iv[AES_IVSIZE];
uint8_t key[32];

if(!csrand_init()) return 1;
csrand_fill(iv, sizeof iv);
csrand_fill(key, sizeof key);

aes_init(&ctx, key, sizeof key, iv, AES_MODE_CTR | AES_CTR_NONCELEN(12) | AES_CTR_COUNTERLEN(4));

aes_encrypt(&ctx, <msg>, msglen, <msgout>);

Also once you use a context with encrypt or decrypt, a flag is set linking it to that operation. Attempting to use an encrypt-bound context for decryption or via versa returns AES_INVALID_OPERATION.
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 2 of 2
» All times are UTC - 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