Remove the ability to select a custom public exponent via domain parameters
in RSA key generation. The only way to select a custom public exponent is
now to pass custom production parameters to psa_generate_key_ext().
A subsequent commit will remove domain parameters altogether from the API,
thus this commit does not bother to update the documentation.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
"Key generation method" was misleading since it also applies to key
derivation. Change "key generation" to "key production", which we aren't
using yet and has roughly the right intuition. Change "method" to
"parameters" which there seems to be a slight preference for. Discussion
thread: https://github.com/Mbed-TLS/mbedtls/pull/8815#discussion_r1486524295
Identifiers renamed:
psa_key_generation_method_t → psa_key_production_parameters_t
psa_key_generation_method_s → psa_key_production_parameters_s
PSA_KEY_GENERATION_METHOD_INIT → PSA_KEY_PRODUCTION_PARAMETERS_INIT
method → params
method_data_length → params_data_length
default_method → default_production_parameters
psa_key_generation_method_is_default → psa_key_production_parameters_are_default
setup_key_generation_method → setup_key_production_parameters
key_generation_method_init → key_production_parameters_init
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Custom-e RSA key generation is not yet supported in the test driver, and we
don't support fallback from the test driver to the built-in
implementation (even though we're testing with MBEDTLS_RSA_C). So for the
time being, only run psa_generate_key_ext test cases for RSA with a custom
public exponent when using the built-in implementation.
Add a test case to validate that psa_generate_key_ext test cases for RSA
with a custom public exponent returns NOT_SUPPORTED (rather than silently
doing the wrong thing) when not using built-in RSA (which is subtly
different from when having accelerated RSA: if both are enabled, which we
currently don't do in all.sh, then this should be supported and this is
validated by the test cases above).
This wart will be resolved when we add support for drivers with a
generate_key_ext entry point.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Instead of passing the size of the whole structure, just pass the data
length and let the implementation worry about adding the size of the
structure. The intent with passing the structure size was to allow
the client code in a client-server implementation to know nothing
about the structure and just copy the bytes to the server. But that was not
really a useful consideration since the application has to know the
structure layout, so it has to be available in the client implementation's
headers. Passing the method data length makes life simpler for everyone by
not having to worry about possible padding at the end of the structure, and
removes a potential error condition
(method_length < sizeof(psa_key_generation_method_t)).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Implement and unit-test the new functions psa_generate_key_ext() and
psa_key_derivation_output_key_ext(), only for the default method.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This feature was an unofficial extension which was never documented.
Now that we are removing the PK dependency in order to use only
functions from RSA module, PEM support is unavailable. Therefore
we explicitly remove it.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
This commit also updates "test_suite_psa_crypto.data" replacing
PSA_ERROR_NOT_SUPPORTED with PSA_ERROR_INVALID_ARGUMENT when
a wrong bit size is provided while importing key.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
`psa_get_key_attributes` depends on some built-in
implementation of RSA. Guard the check with coresponding
macros.
Signed-off-by: Pengyu Lv <pengyu.lv@arm.com>
Some are about raw or AES keys where PK seems really unrelated.
The others are about RSA where PK may be relevant, but the necessary
bits of PK are auto-enabled when RSA key types are requested, so we
shouldn't need to list them as dependencies in tests.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Since _DERIVE can't be accelerated now, in
config_adjust_legacy_from_psa.h we will notice and auto-enable ECP_LIGHT
as well as the built-in version of each curve that's supported in this
build. So, we don't need to list those as dependencies here - and they
would cause issues when we add support for _DERIVE drivers.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
There's no reason the tests would depend specifically on our built-in
implementation and not work with drivers, so replace the RSA_C
dependency with the correct PSA_WANT dependencies.
Those 6 cases use two different test functions, but both of those
functions only do `psa_import()`, so all that's needed is PUBLIC_KEY or
KEYPAIR_IMPORT (which implies KEYPAIR_BASIC) depending on the kind of
key being tested.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Most of them were removed in 7162, not sure how these ones slipped in.
There's no reason deterministic ECDSA verification would need PK parse
more than the other tests. The following finds no match:
grep -i pk_parse library/ecdsa.c library/psa_crypto_ecp.c
Even if PK parse was actually needed for this, the right way would be to
auto-enable it based on PSA_WANT symbols, and then only depend on
PSA_WANT symbols here.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
If MBEDTLS_BLOCK_CIPHER_NO_DECRYPT, we can't test decrypt for
AES-ECB, so adding this dependency for some test cases
Signed-off-by: Yanray Wang <yanray.wang@arm.com>
"Fix PBKDF2 with empty salt on platforms where malloc(0)=NULL" took care of
making an empty salt work. But it didn't fix the case of an empty salt
segment followed by a non-empty salt segment, which still invoked memcpy
with a potentially null pointer as the source. This commit fixes that case,
and also simplifies the logic in the function a little.
Test data obtained with:
```
pip3 install cryptodome
python3 -c 'import sys; from Crypto.Hash import SHA256; from Crypto.Protocol.KDF import PBKDF2; cost = int(sys.argv[1], 0); salt = bytes.fromhex(sys.argv[2]); password = bytes.fromhex(sys.argv[3]); n = int(sys.argv[4], 0); print(PBKDF2(password=password, salt=salt, dkLen=n, count=cost, hmac_hash_module=SHA256).hex())' 1 "" "706173737764" 64
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
