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.
First of all, it had a failure in SEED:
LTC_KSEED failed for x=0, I got:
expected actual (ciphertext)
5e == 5e
ba == ba
c6 == c6
e0 == e0
05 != 00
4e != 00
16 != 00
68 != 00
19 == 19
af == af
f1 == f1
cc == cc
6d != 00
34 != 00
6c != 00
db != 00
Since SEED uses the 32H macros, this is really analogous to the
problem I saw with the 64H macros in Camellia with gcc. Not sure why
gcc only had a problem with 64H and not 32H, but since this is an
interaction with the optimizer, it's not going to happen every time
the macro is used (hence why the store tests pass; only when you get
into the complexity of a real cipher do you start having problems) and
it makes sense it will vary from compiler to compiler.
Anyway, I went ahead and added the ability to use __builtin_bswap32,
in addition to __builtin_bswap64, which I already did in a previous
commit. This solves the problem for clang, although I had to add new
logic to detect the bswap builtins in clang, since it has a different
way to detect them than gcc (see the comments in the code). The
detection logic was complicated enough, and applied to both the 32H
and 64H macros, so I factored out the detection logic into
tomcrypt_cfg.h.
This produces slightly better performance than the inline assembly,
and has the added benefit that it should be portable to other systems
that use gcc, not just x86-64.
Here are the results on my "AMD Athlon(tm) 7450 Dual-Core Processor"
with "gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3":
with portable 64H macros:
camellia : Schedule at 1659
camellia [ 23]: Encrypt at 431, Decrypt at 434
whirlpool : Process at 55
with inline assembly (with "memory clobber" for correctness):
camellia : Schedule at 1380
camellia [ 23]: Encrypt at 406, Decrypt at 403
whirlpool : Process at 50
with __builtin_bswap64:
camellia : Schedule at 1352
camellia [ 23]: Encrypt at 396, Decrypt at 391
whirlpool : Process at 46
This had been causing Camellia (the only cipher that uses these
macros) to fail when compiling "out-of-the-box" with gcc version
"4.3.3-5ubuntu4". I think because the compiler had no idea any memory
access was going on in these macros.
Adding "memory" as a clobber solves the problem, but is probably
overkill. I suspect that if we specify the constraint for y
differently, we could get rid of both "memory" and __volatile__, which
would allow the compiler to optimize much more.
Also, in gcc versions that support it, we should probably use the
bswap builtins instead.
This seemed to be the only place in the code that was using this
particular transposition. And, indeed, when compiling with
"GMP_DESC", it looks like it is necessary to disable Diffie-Hellman.
(Otherwise, the test fails for me.)
