The only real contraint on the raw buffer is that it is large
enough to contain 2 coordinates. Larger buffers are therefore
allowed and the extra data will simply be ignored.
Note = trying to impose a strict sizing on the raw buffer causes
several failures in test suites. This suggests that it is
quite common to use larger buffer to store raw signatures.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Use PSA_VENDOR_ECC_MAX_CURVE_BITS instead of a specific curve since
what we care about is only bit-size not the curve itself.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
These values are not mathematically valid as signature, but as
for what it concerns with ECDSA conversion functions, 0 values
in DER format should be translated to 0 values in raw format.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Allow the function to support DER buffers than what it is nominally
required by the provided coordinates. In other words let's ignore
padding zeros in the raw number.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
A new test function is added, ecdsa_raw_to_der_incremental, that tests
incremental output DER buffer sizes checking that only the correct one
(tested at last) works correctly.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This commit also fixes test_suite_psa_crypto_util.data due to the
change in one of the return values.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Tests with 256 bits curve simply depends on any curve of that size,
but they don't really care about which family is enabled.
Here I replaced PSA_WANT_ECC_SECP_R1_256 with PSA_WANT_ECC_SECP_K1_256
because otherwise there were test disparities in the
"analyze_driver_vs_reference_tfm_config" component of
"analyze_outcomes.py". It looked simpler to change the curve type
in the test suite's data rather than adding proper exceptions
in "analyze_outcomes.py"
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
