Separate the fits-in-buffer check (*data_length <= data_size) from the
we-think-it's-a-sensible-size check (*data_length <=
MBEDTLS_X509_MAX_DN_NAME_SIZE).
This requires using an intermediate buffer for the DER data, since its
maximum sensible size has to be larger than the maximum sensible size for
the payload, due to the overhead of the ASN.1 tag+length.
Remove test cases focusing on the DER length since the implementation no
longer has a threshold for it.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix the expected output in some test cases.
Add a few more test cases to exercise both a payload length around 256 bytes
and a DER length around 256 bytes, since both are placed in a 256-byte
buffer (value of MBEDTLS_X509_MAX_DN_NAME_SIZE).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Due to differing validations amongst X.509 library functions, there are
inputs that mbedtls_x509_string_to_names() accepts, but it produces output
that some library functions can't parse. Accept this for now. Do call the
functions, even when we don't care about their return code: we're ok with
returning errors, but not with e.g. a buffer overflow.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Rename the function from parse_attribute_value_der_encoded: the hex aspect
seems important.
There was a buffer overflow due to not validating that the intermediate data
fit in the stack buffer. The rewrite doesn't use this buffer, and takes care
not to overflow the buffer that it does use.
Document all that's going on.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In particular, "X509 String to Names: long hexstring (DER=258 bytes, too long)"
causes a buffer overflow in parse_attribute_value_der_encoded().
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
More key management operations only require ECP_LIGHT, except:
- generate (scalar multiplication)
- export (exporting public from private also needs scalar
multiplication).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The usual order is:
- MBEDTLS_PSA_BUILTIN_xxx macro
- MBEDTLS_xxx legacy macros
But curves had it the other way round for some reason.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Before this PR, the tests passed without this, but they shouldn't have.
Accelerators need to declare what curves they support, and if no curve
is declared as accelerated, the built-in implementations of algs and key
types need to be enabled.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The previous fix was enabling more than needed in some circumstances,
for example:
- requested: (`PSA_WANT`): all ECC algs, all ECC key types, all curves;
- we have acceleration (`MBEDTLS_PSA_ACCEL`) for: ECDH, all ECC key types, all curves;
- as a consequence, we need built-in: all algs except ECDH, all ECC key types, all curves.
This is what's happening in test_psa_crypto_config_accel_ecdh which,
before this commit, was failing as built-in ECDH was enabled contrary to
the component's (rightful) expectations.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Those components were introduced in #7103, resolving #6622: Some PSA
ECC size macros are too small when the largest accelerated curve is
larger than the largest built-in curve.
At that point, it was not possible yet to omit all built-in curves,
so we made these components that had only one (small) curve built-in and
all the others accelerated.
Now that it's possible to disable all ECC built-ins, and we have tests
doing that, we don't need that kind of fiddling any more.
Note: these component disabled RSA in order to make sure max key size
macros were not taken from RSA. We have test components with all of ECC
accelerated and RSA disabled
(component_test_psa_crypto_config_accel_ecc_no_bignum and
component_test_psa_crypto_config_accel_ecc_ffdh_no_bignum), making the
"all curves except one" components really redundant.
Note: removing them was one of the items in #7757.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Centralize it in a new file psa/config_adjust_keypair_types.h. I think
this file indeed belongs in include/psa (as opposed to include/mbedtls)
because it only touches PSA_WANT symbols (no MBEDTLS_PSA symbols), and
implements things that are described in psa-conditional-inclusion.md.
The code is not new, just moved from config_psa.h and
config_adjust_legacy_from_psa.h where is was intermingled with handling
of ACCEL/BUILTIN symbols. (git's --color-moved option will hardly help
in checking that assertion, due to the way things were intermixed.)
Note: the parts about BUILTIN in config_psa.h were not moved, just
removed for now. They belong to
include/mbedtls/config_adjust_legacy_from_psa.h and will be
re-added there in a future commit which will completely re-organize the
handling or ACCEL/BUILTIN for ECC.
See comments inside the commit about placement of this file relative to
others.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This slightly changes the previous requirement. Instead of enabling
ALL builtin EC algs when there is at least 1 built in curve, we ask
for at least one built alg if there is at least one builtin curve.
This relaxes the previous check while still keeping the base idea:
there must be a reason for which builtin curves are included into
the build.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
