It is easier to read if the parameter controlling constant timeness with
respect to a parameter is next to that parameter.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The complexity of having functions whose security properties depend on a
runtime argument can be dangerous. Limit misuse by making any such
functions local.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Attempt to partially solve the performance regression in 3.6.0 without
adding too much code size.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The conversion back to signed short is an issue: the uint cast results
in (-1 + UINT_MAX), which is OK. But then that can't be cast back to a
signed value: "if the new type is signed and the value cannot be
represented in it; either the result is implementation-defined or an
implementation-defined signal is raised."
Signed-off-by: Janos Follath <janos.follath@arm.com>
When generated by exp_mod, RR has enough limbs to be passed as a
parameter to core functions. If it is received from the caller, it might
be of any length.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Removing E_core and returning early achieves the same and is simpler
(easier to read and maintain).
Signed-off-by: Janos Follath <janos.follath@arm.com>
memcpy() has the advantage of making the reader stop and arguably signal
that the shallow copy here is intentional. But that hinges on having the
right amount of & and the right size. An assignment is clearer and less
risky.
Signed-off-by: Janos Follath <janos.follath@arm.com>
- We have moved to fixed window exponentiation and the algorithm used is
properly documented and referenced in core already, no need for
duplication.
- A comment on mbedtls_mpi_copy states that mbedtls_mpi_exp_mod relies
on it not to shrink X. This is not the case anymore, however we
should probably still state that some functions might rely on this
property as we don't know it for sure and it is safer to keep it that
way.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The two algorithms are not equivalent. The original bignum
exponentiation was a sliding window algorithm. The one in
mpi_core_exp_mod uses a fixed window approach. This change is
intentional. We don't want to maintain two algorithms and decided to
keep the fixed window algorithm.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Conflicts:
* `include/mbedtls/build_info.h`: a new fragment to auto-enable
`MBEDTLS_CIPHER_PADDING_PKCS7` was added in
c9f4040f7f in `development-restricted`.
In `development`, this section of the file has moved to
`include/mbedtls/config_adjust_legacy_crypto.h`.
* `library/bignum.c`: function name change in `development-restricted` vs
comment change in development. The comment change in `development` is not
really relevant, so just take the line from `development-restricted`.
Clear some confusion between `X` as the output variable and "X" as a name
given to the accumulator. Previous iterations of the code used the variable
`X` as the accumulator, but now that the accumulator is `W[x_index]`, some
of the comments didn't make sense.
Remove the copy of the initial value of `X` into `W[x_index]`, which was
meaningless: the initial value of an output variable should not, and did
not, matter. `W[x_index]` is later overridden unconditionally to take the
value `RR`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
