generate_key is a more classical name. The longer name was only
introduced to avoid confusion with getting a key from a generator,
which is key derivation, but we no longer use the generator
terminology so this reason no longer applies.
perl -i -pe 's/psa_generate_random_key/psa_generate_key/g' $(git ls-files)
Generators are mostly about key derivation (currently: only about key
derivation). "Generator" is not a commonly used term in cryptography.
So favor "derivation" as terminology. Call a generator a key
derivation operation structure, since it behaves like other multipart
operation structures. Furthermore, the function names are not fully
consistent.
In this commit, I rename the functions to consistently have the prefix
"psa_key_derivation_". I used the following command:
perl -i -pe '%t = (
psa_crypto_generator_t => "psa_key_derivation_operation_t",
psa_crypto_generator_init => "psa_key_derivation_init",
psa_key_derivation_setup => "psa_key_derivation_setup",
psa_key_derivation_input_key => "psa_key_derivation_input_key",
psa_key_derivation_input_bytes => "psa_key_derivation_input_bytes",
psa_key_agreement => "psa_key_derivation_key_agreement",
psa_set_generator_capacity => "psa_key_derivation_set_capacity",
psa_get_generator_capacity => "psa_key_derivation_get_capacity",
psa_generator_read => "psa_key_derivation_output_bytes",
psa_generate_derived_key => "psa_key_derivation_output_key",
psa_generator_abort => "psa_key_derivation_abort",
PSA_CRYPTO_GENERATOR_INIT => "PSA_KEY_DERIVATION_OPERATION_INIT",
PSA_GENERATOR_UNBRIDLED_CAPACITY => "PSA_KEY_DERIVATION_UNLIMITED_CAPACITY",
); s/\b(@{[join("|", keys %t)]})\b/$t{$1}/ge' $(git ls-files)
In psa_import_key, change the order of parameters to pass
the pointer where the newly created handle will be stored last.
This is consistent with most other library functions that put inputs
before outputs.
In psa_generate_derived_key, change the order of parameters to pass
the pointer where the newly created handle will be stored last.
This is consistent with most other library functions that put inputs
before outputs.
Read extra data from the domain parameters in the attribute structure
instead of taking an argument on the function call.
Implement this for RSA key generation, where the public exponent can
be set as a domain parameter.
Add tests that generate RSA keys with various public exponents.
Instead of passing a separate parameter for the key size to
psa_generate_key and psa_generator_import_key, set it through the
attributes, like the key type and other metadata.
This commit starts a migration to a new interface for key creation.
Today, the application allocates a handle, then fills its metadata,
and finally injects key material. The new interface fills metadata
into a temporary structure, and a handle is allocated at the same time
it gets filled with both metadata and key material.
This commit was obtained by moving the declaration of the old-style
functions to crypto_extra.h and renaming them with the to_handle
suffix, adding declarations for the new-style functions in crypto.h
under their new name, and running
perl -i -pe 's/\bpsa_(import|copy|generator_import|generate)_key\b/$&_to_handle/g' library/*.c tests/suites/*.function programs/psa/*.c
perl -i -pe 's/\bpsa_get_key_lifetime\b/$&_from_handle/g' library/*.c tests/suites/*.function programs/psa/*.c
Many functions that are specific to the old interface, and which will
not remain under the same name with the new interface, are still in
crypto.h for now.
All functional tests should still pass. The documentation may have
some broken links.
platform.h should only be used internally by the library implementation
itself, not the examples. Remove the dependency on platform.h from all
PSA programs.
When `MBEDTLS_PLATFORM_C` is not enabled, our PSA Crypto implementation
depends on the standard C library for functions like snprintf() and
exit(). However, our implementation was not including the proper header
files nor redefining all `mbedtls_*` symbols properly to ensure
successful builds without MBEDTLS_PLATFORM_C. Add the necessary header
files and macro definitions to our PSA Crypto implementation.
When MBEDTLS_CHECK_PARAMS is enabled, it's required to have an
implementation of mbedtls_param_failed() present. Without it in the PSA
examples, building the PSA examples will result in linker errors like
the following.
../../library/libmbedcrypto.a(rsa.c.o): In function `mbedtls_rsa_import':
rsa.c:(.text+0x9fd): undefined reference to `mbedtls_param_failed'
../../library/libmbedcrypto.a(rsa.c.o): In function `mbedtls_rsa_import_raw':
rsa.c:(.text+0xb0b): undefined reference to `mbedtls_param_failed'
../../library/libmbedcrypto.a(rsa.c.o): In function `mbedtls_rsa_complete':
rsa.c:(.text+0xe63): undefined reference to `mbedtls_param_failed'
../../library/libmbedcrypto.a(rsa.c.o): In function `mbedtls_rsa_export_raw':
rsa.c:(.text+0xfee): undefined reference to `mbedtls_param_failed'
../../library/libmbedcrypto.a(rsa.c.o): In function `mbedtls_rsa_export':
rsa.c:(.text+0x116f): undefined reference to `mbedtls_param_failed'
../../library/libmbedcrypto.a(rsa.c.o):rsa.c:(.text+0x1304): more undefined
references to `mbedtls_param_failed' follow
collect2: error: ld returned 1 exit status
programs/psa/CMakeFiles/crypto_examples.dir/build.make:97: recipe for target
'programs/psa/crypto_examples' failed
make[2]: *** [programs/psa/crypto_examples] Error 1
Add an implementation of mbedtls_param_failed() to the PSA Crypto
examples to avoid getting this error on the PSA examples.
Remove the type and bits arguments to psa_allocate_key() and
psa_create_key(). They can be useful if the implementation wants to
know exactly how much space to allocate for the slot, but many
implementations (including ours) don't care, and it's possible to work
around their lack by deferring size-dependent actions to the time when
the key material is created. They are a burden to applications and
make the API more complex, and the benefits aren't worth it.
Change the API and adapt the implementation, the units test and the
sample code accordingly.
Add new initializers for key policies and use them in our docs, example
programs, tests, and library code. Prefer using the macro initializers
due to their straightforwardness.
GCC 4.8 warns that some variables may be used without having been
initialized. They aren't, but determining that takes nontrivial
analysis, so initialize them at the point of definition.
