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