Some of them no longer need md_ctx, some of those no longer need the
exit dance that was used to free it, or need it on a smaller scope.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is a first step towards making a version of this function that
uses PSA when MD is not available.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Since 11e9310 add mbedtls_aes_init call in mbedtls_ctr_drbg_init, it
should not init aes_ctx again in mbedtls_ctr_drbg_seed.
Signed-off-by: kXuan <kxuanobj@gmail.com>
Application may enabled AES_ALT and define mbedtls_aes_context by its own.
The initial state of user-defined mbedtls_aes_context may not all byte zero.
In mbedtls_ctr_drbg_init, the code set all byte to zero, including the AES
context nested in the ctr_drbg context.
And in mbedtls_ctr_drbg_free, the code calls mbedtls_aes_free on an AES
context without calling mbedtls_aes_init.
If user-defined AES context requires an non-zero init, the mbedtls_aes_free
call in mbedtls_ctr_drbg_free is illegal.
This patch fix this issue by add mbedtls_aes_init in mbedtls_ctr_drbg_init.
So aes context will always be initialized to correct state.
Signed-off-by: kXuan <kxuanobj@gmail.com>
Looking at the bigger picture it is clear that if `ssl->session` is NULL,
there will be a failure much earlier, and that is well protected from,
however, the practice of dereferencing a pointer which has not been
verified in prior for validity goes against secure coding practices.
Signed-off-by: Leonid Rozenboim <leonid.rozenboim@oracle.com>
Extract functions declared in bignum_mod.h into a source file with a
matching name.
We are doing this because:
- This is a general best practice/convention
- We hope that this will make resolving merge conflicts in the future
easier
- Having them in a unified source file is a premature optimisation at
this point
This makes library/bignum_new.c empty and therefore it is deleted.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Extract functions declared in bignum_mod_raw.h into a source file with a
matching name.
We are doing this because:
- This is a general best practice/convention
- We hope that this will make resolving merge conflicts in the future
easier
- Having them in a unified source file is a premature optimisation at
this point
Signed-off-by: Janos Follath <janos.follath@arm.com>
Extract functions declared in bignum_core.h into a source file with a
matching name.
We are doing this because:
- This is a general best practice/convention
- We hope that this will make resolving merge conflicts in the future
easier
- Having them in a unified source file is a premature optimisation at
this point
Signed-off-by: Janos Follath <janos.follath@arm.com>
This reverts commit 62c5901f0a5061a8825e19c77f88c91fea235078.
Reverting commit due the macros are meant to be local and not following the
naming convention.
Signed-off-by: Gabor Mezei <gabor.mezei@arm.com>
Unfortunately reusing the new function from the signed constant time
comparison is not trivial.
One option would be to do temporary conditional swaps which would prevent
qualifying input to const. Another way would be to add an additional
flag for the sign and make it an integral part of the computation, which
would defeat the purpose of having an unsigned core comparison.
Going with two separate function for now and the signed version can be
retired/compiled out with the legacy API eventually.
The new function in theory could be placed into either
`library/constant_time.c` or `library/bignum_new.c`. Going with the
first as the other functions in the second are not constant time yet and
this distinction seems more valuable for new (as opposed to belonging to
the `_core` functions.
Signed-off-by: Janos Follath <janos.follath@arm.com>
- We don't check for NULL pointers this deep in the library
- Accessing a NULL pointer when the limb number is 0 as a mistake is the
very similar to any other out of bounds access
- We could potentially mandate at least 1 limb representation for 0 but
we either would need to enforce it or the implementation would be less
robust.
- Allowing zero limb representation - (NULL, 0) in particular - for zero
is present in the legacy interface, if we disallow it, the
compatibility code will need to deal with this (more code size and
opportunities for mistakes)
In summary, interpreting (NULL, 0) as the number zero in the core
interface is the least of the two evils.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The test case where there were extra limbs in the MPI failed and this
commit contains the corresponding fix as well. (We used to use the
minimum required limbs instead of the actual limbs present.)
Signed-off-by: Janos Follath <janos.follath@arm.com>
