The external representation before included more than just endianness
(like reading in Mongtomery curve scalars or converting hashes to
numbers in a standard compliant way).
These are higher level concepts and are out of scope for Bignum and for
the modulus structure.
Passing endianness as a parameter is a step towards removing it from the
modulus structure.
Signed-off-by: Janos Follath <janos.follath@arm.com>
This patch updates the `mbedtls_mpi_mod_raw_conv_xx()` methods
as follows:
* Renamed for simplicity: conv_fwd -> from_mont_rep, conv_inv -> to_mont_rep.
* Uncoupled the dependency on the legaly bignum interface.
* `mbedtls_mpi` is no longer used for temporary buffer allocation.
Signed-off-by: Minos Galanakis <minos.galanakis@arm.com>
Legacy Bignum is excluded as it doesn't get regular extensions like new
ones.
Each slot uses comments of their respective filetype. Since .data files
don't have a syntax for comments, dummy test cases are used. (These test
cases will never be executed and no noise will be added to tests.)
Signed-off-by: Janos Follath <janos.follath@arm.com>
There was already a short introduction to _who_ should use each module, but
not to _what_ each module does.
Signed-off-by: Gilles Peskine <Gilles.Peskine@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>
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>
