md: keep contexts for HMAC in GcryDigestEntry.
authorNIIBE Yutaka <gniibe@fsij.org>
Thu, 22 Oct 2015 00:58:24 +0000 (09:58 +0900)
committerNIIBE Yutaka <gniibe@fsij.org>
Thu, 22 Oct 2015 00:58:24 +0000 (09:58 +0900)
commitf7505b550dd591e33d3a3fab9277c43c460f1bad
tree5c88de89d47eb6969ce271e111057b023159413c
parent1c6d2698a84e4bf82735287c1d64954bfc1a1982
md: keep contexts for HMAC in GcryDigestEntry.

* cipher/md.c (struct gcry_md_context): Add flags.hmac.
Remove macpads and mcpads_Bsize.
(md_open): Initialize flags.hmac.  Remove macpads initialization.
(md_enable): Allocate contexts when flags.hmac is enabled.
(md_copy): Remove macpads copying.  Add copying contexts.
(_gcry_md_reset): When flags.hmac is enabled, restore precomputed
context with input pad
(md_close): Remove macpads wiping.
(md_final): When flags.hmac is enabled, compute hmac by precomputed
context with output pad.
(prepare_macpads): Prepare precomputed contexts with input pad and
output pad for each registered digest entry.
(_gcry_md_setkey): Just call prepare_macpads.

--

This change is making things straight in HMAC computation.  This makes
HMAC computation allow multple algorithms in future.

Libgcrypt's code has a potential to compute digests for multiple
algorithms at once (currently, it's not enabled).  HMAC code didn't
work well with multple algorithms, because the macpads were only
allocated for an algorithm.  Now, it's allocated for each algorithm.

We now precompute hash contexts, instead of keeping input pad and
output pad.  This can be performance improvement, which is described
in RFC 2104.

Thanks to:

   Andrea Visconti, Simone Bossi, Hany Ragab and Alexandro Calò

For the discussion and their paper of CANS2015, which titled:

   On the weaknesses of PBKDF2
cipher/md.c