Note: this section shouldn't actually be updated in #8357, but
rather in #8358 which is the wrapup related to cipher and AEADs
accelaration. As a consequence we start the AEAD section with
a disclaimer explaining that the information written there will
be updated soon by a follow up PR.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Using a dedicated field allows clean separatin between key attributes
and slot state. This allows us to use the same mechanics for attributes
and key content. Which in turn means lower code size and easier
maintenance.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Separate design analysis from plans and make the distinction clear
between what is implemented, what is planned to be implemented soon,
what is planned to be implemented in the future, and what is ideas that
are rejected.
(The distinction between the last two categories doesn't have to be
clear, we can't and shouldn't plan that far ahead.)
Signed-off-by: Janos Follath <janos.follath@arm.com>
Latest changes:
- logic about the relationship between curves, key types and algs (8075)
- building without bignum is no longer "coming soon", it's there :)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
There was a bit of a race condition between #8041 which introduced the
new entry points, and #8203 which documented the list of entry points.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Now that p256-m is officially a production feature and not just an example,
give it a more suitable name.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
State explicitly the non-requirement that it's ok for psa_destroy_key to
block waiting for a driver.
Signed-off-by: Janos Follath <janos.follath@arm.com>
- Use unique section titles so that there are unique anchors
- Make list style consistent between similar sections
Signed-off-by: Janos Follath <janos.follath@arm.com>
We shouldn't violate the requirement that the key identifier can be
reused. In practice, a key manager may destroy a key that's in use by
another process, and the privileged world containing the key manager and
the crypto service should not be perturbed by an unprivileged process.
With respect to blocking, again, a key manager should not be blocked
indefinitely by an unprivileged application.
These are desirable properties even in the short term.
Signed-off-by: Janos Follath <janos.follath@arm.com>
- the codegen migration document is already a migration document, so
doesn't need the extra warning about work in progress;
- the driver interface can use a link to the more practical guide too.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
