...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...
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'.
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
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.
