An ARM compiler gives me this:
libtomcrypt\pk\asn1\der\sequence\der_decode_subject_public_key_info.c(65,4): error #188-D: enumerated type mixed with another type
Since der_decode_subject_public_key_info's parameters_type is of type 'unsigned long', an attempt to assign it to ltc_asn1_list's member 'ltc_asn1_type type' fails.
My fix solves this in a simple way by casting it at the point of assignment.
But while studying this I noticed there's no use of enum in the codebase other than a few PK-related things. Perhaps a more appropriate solution would be to remove these enums. I mean, enums seem like an OK enough idea, but I don't know anything about the practicality of using enums in archaic C dialects like libtomcrypt conforms (thankfully!) to...
...someone could then do something like this...
unsigned char* out = NULL;
unsigned long len = 0;
while(ecc_ansi_x963_export(key, out, &len) == CRYPT_BUFFER_OVERFLOW &&
len == 0) {
out = malloc(len);
}
...as if someone would ever like to do something like that...
instead of two different buffers, there is just one buffer. Based upon the verification result, a mask is applied to the buffer before it is written to the output buffer.
Create two buffers of the same size as the input data.
Copy the input data to the first one and work with that version to hold the
decrypted data, zeroize the second one.
Copy depending on the verification result, either the zero-buffer or the
real plaintext to the output buffer.
The API of the function is changed (for decryption, tag is now an input
parameter). With the old API it is impossible to confirm to the NIST
specification and a timing sidechannel leak is inevitable.
