Hello,
вт, 24 июл. 2018 г. в 15:40, Niels Möller <[email protected]>:
> 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.
--
With best wishes
Dmitry
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
