Hello,
вт, 24 июл. 2018 г. в 15:40, Niels Möller nisse@lysator.liu.se:
This reinit function is used instead of a plain memcpy (of the complete ctx, including buffer). That's less efficient, since we'll get more calls to the heavy compression function for each message.
True. I'll look into adding HMAC functions to nettle-benchmark then. It would be interesting to compare performance.
struct sha256_state { uint32_t state[_SHA256_DIGEST_LENGTH]; /* State variables */ uint64_t count; /* 64-bit block count */ unsigned int index; /* index into buffer */ };
struct sha256_ctx { struct sha256_state state; uint8_t block[SHA256_BLOCK_SIZE]; /* SHA256 data buffer */ };
It might be worth moving both index and block out of 'state' function and then updating compress/MD_* macros to accept separate 'compression state' and 'buffer state' structures. This might result in some code cleanups. I'll give this idea a thought.
and let
struct hmac_sha256 { struct sha256_state inner; struct sha256_state outer; struct sha256_ctx hash_ctx; /* Initialized from key, updated as the message is processed */ };
We'd need to add a state_size field to struct nettle_hash, and then reinit would be
memcpy(&hmac_ctx->hash_ctx, hmac_ctx->inner /* or outer */, hash->state_size);
And the nice thing is that any hash function not matching this internal structure can let state_size == context_size, and things will keep working.
What do you think?
What about having following functions:
_FOO_init(state); FOO_init(ctx); _FOO_compress(state, block[]) FOO_update(ctx, length, data); _FOO_digest(state, buffer_state); FOO_digest(ctx);
Users will call typical FOO_* functions, while HMAC code can call internal _FOO_* functions.