dkg at fifthhorseman
Nov 28, 2009, 8:33 PM
Post #1 of 1
(401 views)
Permalink
|
|
should HMAC digests require secure memory?
|
|
Hi gcrypt folks--
it looks to me like cipher/md.c:487 effectively requires secure memory
for HMAC-enabled digest objects, whether or not GCRY_MD_FLAG_SECURE was set.
This is a surprising behavior, since (at least in versions before
1.4.3), it can lead to an "Ohhhh jeeee: operation is not possible
without initialized secure memory" error message, followed by the
process being aborted.
Since version 1.4.3 (according to NEWS) this appears to be worked around
by auto-allocating 32K secure memory if the library isn't otherwise
initialized.
I note that in the older gcrypt versions vulnerable to this failure, an
explicit call to gcry_control(GCRYCTL_DISABLE_SECMEM) before creating
the HMAC-enabled will avoid the failure.
I wonder if modern libraries are still subject to this failure if
they're run by users unable to allocate secure memory (and thus the
default allocation of 32K of secmem would fail). i don't have such a
system handy to try.
Why are ctx->maxpads allocated securely, even if GCRY_MD_FLAG_SECURE is
not set?
It seems to me like this should be normalized in one of the following ways:
0) documentation for gcry_md_open should note that secure memory is
used when GCRY_MD_FLAG_HMAC is used, regardless of GCRY_MD_FLAG_SECURE.
1) allocation of ctx->maxpads in md_open() should allocate secure or
normal memory based on the "secure" argument to that function.
Are there other ways this behavior could be made less surprising?
Regards,
--dkg
|
signature.asc
