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.
mem_neq is no more used directly. XMEM_NEQ is used instead,
in the same way XMEMCMP, XMEMCPY,... are.
Signed-off-by: Pascal Brand <pascal.brand@st.com>
as proposed in RFC 3447 only one error return code is used when there are
errors while decoding the pkcs#1 format.
also, all steps are executed and only the "output" is skipped if something
went wrong.
Sorry this could break backwards compatibility, since there's no more
BUFFER_OVERFLOW messaging.
Former error-handling code could also be affected because now there's only
OK as return code in cases where "res" is also set to '1'.
CCM is only meant for packet mode where the length of the input is known in
advance. Since it is a packet mode function, CCM only had one function that
performs the protocol.
However, incremental authentication is usefull in some usecases. It also
ensure some kind of coherencies when processing with a given authentication
mode or another. To achieve this aim, this commit adds the following functions:
ccm_init()
ccm_add_aad()
cm_add_nonce()
ccm_process()
ccm_done()
ccm_reset()
as well as the data structure
ccm_state
Change-Id: I5225a42bb098708c4af07518b561bb00f85bc243
multiple xts_encrypt() cannot be performed because the
tweak is not updated. That means that
xts_encrypt(buffer1, tweak)
xts_encrypt(buffer2, tweak)
is not the same as
xts_encrypt(concat(buffer1, buffer2), tweak)
Current patch enables such functionalities by
updating the tweak as output of the encryption.
Note that the tweak is no more constant.
The very same modification is performed
on xts_decrypt()
Signed-off-by: Pascal Brand <pascal.brand@st.com>
rsa_exptmod(), ran on the private key, makes use of CRT optimization
parameters. In some use-cases, the given key does not include the
optimization parameters.
This patch allows rsa_exptmod() to run without the CRT parameters,
using directly mp_exptmod().
Signed-off-by: Pascal Brand <pascal.brand@st.com>
unsigned long is 32bit wide when compiling with the compiler flag "-mx32"
but the digit size of the math libraries is still 64 bit which lead to
the buggy ecc code.
Therefore define a new type ltc_mp_digit with the correct width and use
that as return value of get_digit()
Has been tested with all three math providers
The existing LTC code for padding meassages for PSS signatures
contained a small error. In particular, the PSS-passing algorithms is
supposed to be given (bitlength of key - 1) as an argument. The LTC
code passes (bitlength of key), and subtracts 1 in the middle of the
PSS-padding. This subtraction unfortunately comes too late: a
calculation using that argument has already been made. Fortunately,
this bug only appeared if the bit-length of the key was 1 mod 8, and
so is unlikely to show up in practice. Still, this patch fixes the
problem.
Conflicts:
src/pk/pkcs1/pkcs_1_pss_decode.c
Because many of the hash-functions implemented by LTC use the length
of the input when padding the input out to a block-length, LTC keeps
track of the input length in a 64-bit integer. However, it did not
previously test for overflow of this value. Since many of the
hash-functions implemented by LTC are defined for inputs of length
2^128 bits or more, this means that LTC was incorrectly implementing
these hash functions for extremely long inputs. Also, this might have
been a minor security problem: A clever attacker might have been able
to take a message with a known hash and find another message (longer
by 2^64 bits) that would be hashed to the same value by LTC.
Fortunately, LTC uses a pre-processor macro to make the actual code
for hashing, and so this problem could be fixed by adding an
overflow-check to that macro.
There would have been a call to mp_clear_multi() of all the key parameters
that are not yet allocated, in the case where the calculations of p, q,
tmp1 or tmp2 created an error.
This also includes a proposed improvement from the OLPC project to free
elements in the reverse order as they were allocated.
There could have been a 'goto error', which misses the free of rnd and
rndi even if they were initialized.
This could happen in cases where a private key operation was done and
afterwards one of the operations like reading back or conversion, would
have failed (which is likely not to happen)
This also includes a proposed improvement from the OLPC project to free
elements in the reverse order as they were allocated.
