This is a preparatory step in order to be able to organize the include
chain from crypto_struct in such a way that the MAC operation structure
for the PSA 'software' driver can make use of the hash operation structure.
Conceptually:
* Primitives:
* Hash
* Cipher
* Composites:
* AEAD (can use cipher)
* MAC (can use cipher and/or hash)
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
This algorithm is used for example by the Thread 1.1.1 specification,
which is not public but can be obtained free of charge at
https://www.threadgroup.org/ThreadSpec
Here it doesn't really make sense to define a parametrised family, as
this really seems to be the only use of PBKDF2 with a CMAC-based PRF (or
with any PRF other than HMAC with SHA1 or SHA2, for that matter).
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Might make the implementer's life a bit simpler, and is not a big
constraint on applications.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
No change of behaviour, encoding or naming intended in this commit: just
describe the same behaviour, but in a way that's hopefully clearer and
more complete.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Note on naming: previously considered input_numeric but then thought the
other two input function are "input <name>" not "input <adjective>" so
decided to follow that pattern. input_int would be shorter but sounds
too much like the C type, which could be confusing as that's not the
type of the parameter; IMO "integer" avoids that problem.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
For the numeric values, I followed the apparent existing convention:
- first byte is 01 for secret inputs, 02 for non-secret inputs
- then second by is just incremented for each new input type
The documentation references a function that will be introduced in the
next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The documentation references functions that will be introduced in later
commits, but hopefully from the naming it's already clear what those
function will do.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Question to reviewers: regarding the numeric values, I'm not sure I've
incremented the right byte/nibble. Should this be 0x1201, 0x1202
instead, or something else? Is there a convention I should be aware of?
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Specifically allow the driver to override the persistency level of a
builtin key in cases where the driver is persistency-aware.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Due to repeated calls to PSA_AEAD_NONCE_LENGTH, which in turn calls
PSA_ALG_AEAD_WITH_DEFAULT_LENGTH_TAG several times, some macros updated
in this PR expanded to over 6000 characters, more than the 4095 that ISO
C99 compilers are guaranteed to support.
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Instead of the full attributes struct, it now only takes/returns what it
actually needs to.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
According to the design in psa-driver-interface.md. Compiles without
issue in test_psa_crypto_drivers.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Where a change was necessary, the new documentation was copied from the
PSA Crypto API spec exactly, with the exception of PSA_AEAD_TAG_LENGTH,
which needed some adjustment.
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
