md2.c was doing memset(m, 0, sizeof(m)), and so was only clearing
the first 4 bytes of the passed md2 structure in MD2_Final. Fix
this to clear the entire structure, as expected.
Heimdal can be executed in environments in which the user
account profile is not loaded. In such environments it is
not possible to use PROV_RSA_FULL as it stores required
data within the profile. Instead, fallback to PROV_RNG which
does not store data within the profile and can be used to access
secure random number generator routines.
Change-Id: If600246f39645ed6bf5af0dd237f5adfddcf6c0c
on a big endian machine, usage of this file in the kernel
is somewhat troublesome since the linux kernel already has
a well known global/#define called current.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
most of these warnings are not problems because of ample
use of abort() calls. However, the large number of warnings
makes it difficult to identify real problems. Initialize
the variables to shut up the compilers.
Change-Id: I8477c11b17c7b6a7d9074c721fdd2d7303b186a8
hcrypto: struct x64 doesn't need bitfields
The bitfield specifications on the struct x64 members do not actually do
anything to guarantee/force packing or endian of the members. Removing
them allows the code to compile on certain compilers that do not support
bitfields on 64-bit types.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
When using 64bit constants for initialisation flag them as LL, so
the compiler doesn't try to cast them down to a long, and throw away
information, on 32 bit platforms.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
EVP_BytesToKey uses min() on a mixture of signed and unsigned
paramters. To avoid compiler warnings, use unsigned int for all
of the iv and key lengths in this function.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
Some kernels define u8, u16 and u32 in their standard headers.
Redefining these symbols in hcrypto's own code prevents that code
from compiling on those kernels.
Instead, just replace all occurrences of u8, u16 and u32 with the
symbols that uint8_t, uint16_t and uint32_t that they were being
typedef'd as, anyway.
Signed-off-by: Love Hornquist Astrand <lha@h5l.org>
