Since at least SDK V6.1 HCRYPTPROV has been specified as ULONG_PTR
this means that comparing or setting one with NULL causes a cast
warning.
Use an explicit cast from zero to that type.
Before committing to a PKCS#11 mechanism, check that it can provide the
required encryption or digest services by validating the flags returned by
C_GetMechanismInfo().
Add a pair of functions which can be used to allocate and free
an HMAC_CTX structure on the heap. This means that the caller doesn't
need to know the size of the underlying structure.
In the interest of being paranoid, when a WinCNG crypto or digest
context is being reinitialized, zero out the backing store as well
as destroying the handle.
This is required as the PKCS#11 library needs to be reinitialized after
forking. This was causing a problem with ipropd.
This fix appears to incur a repeatable 10ms performance penalty on aes-test.
Caching the initialization status using a once control and invalidating it
on fork provided no measurable performance benefit on Solaris 11. Other
approaches would not be thread-safe or would involve more intrusive code
changes, such as exposing heimbase's atomics.
Similar fix to a88d0066, but for the WinCNG EVP backend. However this
is just a fix for leaking handles if the same EVP context is used with
a new key; there is no functionality issue as cipherstate is maintained
directly in the EVP context, not internally by WinCNG.
Clients of the EVP API can reinitialize message digest contexts
without destroying them. The PKCS#11 backend assumed they were
only used once, and was leaking session handles upon reinitialization.
This fix disposes of any existing PKCS#11 message digest context
in the initialization method.
Some callers of EVP_DigestUpdate (such as libntlm) pass NULL as the
data argument. PKCS#11 returns CKR_ARGUMENTS_BAD which may poison
the context. Pass an empty string to C_DigestUpdate work around this.
81c778e broke the PKCS#11 hcrypto backend broke for many cases as it did
not support cipherstate resetting. (Prior to 81c778e, which was to fix#194,
the PKCS#11 backend did not support cipherstate chaining across invocations.)
hcrypto backends that maintain cipherstate independently of the hcrypto
context IV field need to set EVP_CIPH_ALWAYS_CALL_INIT to avoid the two
diverging. Their init function should support resetting the cipherstate
independently of key scheduling.
camellia-ntt had none of its symbols renamed into the hc_ namespace,
and rand's missed timer_method (while all other methods were done). rename
these like we do for others
The correct test for a windows build is if defined(_WIN32), not just
if _WIN32. Fix a few places in the build which do the wrong thing, as
it gives compiler warnings.
All of the hcrypto source files were updated with commit
0f97855826 to include roken.h. This
means that hash.h no longer needs to include the roken header.
Remove the multiple inclusion.
Some portions of libhcrypto are reused by other projects in
diverse environments, including within operating system kernel modules.
In some such build environments, hardening measures such as grsecurity
can (randomly) reorder structure elements, so as to make it harder
for an attacker to determine the offset from a known field's address
to a different field that is needed for an attack.
However, doing so requires the use of C99 designated initializers
to make the source code compatible with such structure rearrangement,
as opposed to the "traditional" C aggregate type initializers, which
just list fields in order. This feature is also available as a
GCC extension since early versions of GCC. However, it is not
provided by many common versions of visual studio (and presumably
also not by the vendor compiler for various commercial Unixes),
so the traditional initializers must remain, behind a conditional.
__GNUC__ or __STDC_VERSION__ >= 199901 should be enough to get
most cases with support for designated initializers, at least
for now.
Signed-off-by: Nicolas Williams <nico@twosigma.com>
For consistency make "-I" part of the macro value set by autoconf.
For now, don't attempt to handle OpenSSL rpath in cf/crypto.m4.
That's much easier by just setting LDFLAGS when running configure.
Otherwise too many Makefiles to edit and libtool and automake do
their best to undo the rpath.
