Co-authored-by: Tom Cosgrove <81633263+tom-cosgrove-arm@users.noreply.github.com>
Co-authored-by: Werner Lewis <werner.wmlewis@gmail.com>
Signed-off-by: Janos Follath <janos.follath@arm.com>
Numbers:
- A, B for mbedtls_mpi_uint* operands
- a, b for mbedtls_mpi_uint operands
- X or x for result
- HAC references where applicable
Lengths:
- Reserve size or length for length/size in bytes or byte buffers.
- For length of mbedtls_mpi_uint* buffers use limbs
- Length parameters are qualified if possible (eg. input_length or
a_limbs)
Setup functions:
- The parameters match the corresponding structure member's name
- The structure to set up is a standard lower case name even if in other
functions different naming conventions would apply
Scope of changes/conventions:
- bignum_core
- bignum_mod
- bignum_mod_raw
Signed-off-by: Janos Follath <janos.follath@arm.com>
In the new bignum files (bignum_core.c, bignum_mod_raw.c and
bignum_mod.c) the loop variables are declared in the loop head wherever
this change is beneficial.
There are loops where the loop variable is used after the end of the
loop (this might not be good practice, but that is out of scope for this
commit) and others where there are several loop variables and declaring
them there would hurt readability.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The modulus value won't change during normal operations, make this clear
in the struct and the function signatures.
This won't prevent the caller from modifying the passed buffer, but
might give a hint and reinforces the message of the documentation.
Signed-off-by: Janos Follath <janos.follath@arm.com>
- Instead of macros, use direct calculations for array sizes
- Move variable declarations closer to first use
Signed-off-by: Janos Follath <janos.follath@arm.com>
Skip reading if output pointer is NULL even if the length of the input buffer is 0.
The memory sanitizer will mark this as an error.
Signed-off-by: Gabor Mezei <gabor.mezei@arm.com>
These functions have full documentation in the header. Maintaing two
copies does not worth the effort and having an out of sync reduced
duplicate is not helpful.
Signed-off-by: Janos Follath <janos.follath@arm.com>
This used to resize MPIs in the legacy interface, which is not
needed/possible as the new interface has fixed size MPIs.
Inlining this function makes the code easier to read and maintain, while
there is no obvious drawback to it.
Signed-off-by: Janos Follath <janos.follath@arm.com>
A null pointer dereference, or null pointer plus small offset, is a
clean runtime error in most environments. So it's not particularly
useful to protect against this.
While at it make a null pointer check that is actually necessary more
robust.
Signed-off-by: Janos Follath <janos.follath@arm.com>
- Made use of enums in struct and function declaration
- All enums are handled by switch case now
- If the switch does nothing on default, omit the default case to make
compiler warnings more powerful
- The two enums are now disjoint and the value 1 is skipped to make
mistakes easier to detect
Signed-off-by: Janos Follath <janos.follath@arm.com>
Internal macros are not present as symbols, visible or usable outside
the compilation unit and it is safe to allow them to have a name without
namespace prefix.
We also allow them to start with lower case letters as some of our
internal macros already have names like that.
Signed-off-by: Janos Follath <janos.follath@arm.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>
