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>
Implementers and users would have to refer to the RFC for the detailed
specification of the algorithm anyway.
Keep a mention of the curves and hashes involved for avoidance of doubt.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The coordinates are over $F_{2^{255}-19}$, so by the general
definition of the bit size associated with the curve in the
specification, the value for size attribute of keys is 255.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The size attribute of a key is expressed in bits, so use bits in the
documentation. (The documentation of psa_export_key() describes the
export format, so it counts in bytes.)
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Call it “SHAKE256-512”, just like SHA3-512 has 512 bits of output.
SHAKE256-64 looks like it's 64 bits of output, but this is 64 bytes.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Define algorithms for PureEdDSA and for HashEdDSA, the EdDSA variants
defined by RFC 8032.
The encoding for HashEdDSA needs to encode the hash algorithm so that
the hash can be calculated by passing PSA_ALG_SIGN_GET_HASH(sig_alg)
to psa_hash_compute() or psa_hash_setup(). As a consequence,
Ed25519ph (using SHA-512) and Ed448ph (using SHAKE256) need to have
different algorithm encodings (the key is enough to tell them apart,
but it is not known while hashing). Another consequence is that the
API needs to recognize the Ed448 prehash (64 bytes of SHAKE256 output)
as a hash algorithm.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add an elliptic curve family for the twisted Edwards curves
Edwards25519 and Edwards448 ("Goldilocks"). As with Montgomery curves,
since these are the only two curves in common use, the family has a
generic name.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Fix places where Doxygen documentation uses \p to refer to a parameter
name and where the name used did not match the actual parameter name.
I used the following script to detect problematic cases:
```
perl -w -ne 'if (eof) { $. = 0; } if (m!^/\*\*!) { $in_doc = 1; %param = (); %p = (); } if (m!\*/!) { foreach $name (keys %p) { if (!$param{$name}) { foreach $line (@{$p{$name}}) { print "$ARGV:$line: $name\n" } } } $in_doc = 0; } if ($in_doc) { if (/\\param(?: *\[[^\[\]]*\])? +(\w+)/) { $param{$1} = 1; } foreach (/\\p +\*?(\w+)/) { push @{$p{$1}}, $.; } }' include/psa/*.h
```
This commits fixes all the remaining occurrences under include/psa,
which were just trivial name mismatches.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This brings them in line with PSA Crypto API 1.0.0
PSA_ALG_AEAD_WITH_DEFAULT_TAG_LENGTH -> PSA_ALG_AEAD_WITH_DEFAULT_LENGTH_TAG
PSA_ALG_AEAD_WITH_TAG_LENGTH -> PSA_ALG_AEAD_WITH_SHORTENED_TAG
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
This algorithm replaces the pre-existing stream cipher algorithms.
The underlying stream cipher is determined by the key type.
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
If the file is read correctly, but it contains data that isn't valid,
the crypto storage code returns PSA_ERROR_DATA_INVALID.
The PSA_ERROR_DATA_CORRUPT and PSA_ERROR_STORAGE_FAILURE error codes are
replaced with PSA_ERROR_DATA_INVALID, except in the ITS subsystem.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Move all the PSA crypto APIs using key handles
to use key identifiers but psa_key_open() and
psa_key_close(). This is done without modifying
any test as key handles and key identifiers are
now the same.
Update the library modules using PSA crypto APIs
to get rid of key handles.
Programs and unit tests are updated to not use
key handles in subsequent commits, not in this
one.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Define psa_key_handle_t to be equal to
mbedtls_svc_key_id_t. Make the handle of a persistent
key be equal to its key identifier. For volatile keys,
make the key handle equal to the volatile key
identifier of the created volatile key.
The unit tests are modified just to make them compile
not to make them run successfully. They are fixed in
the subsequent commits.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Move key identifier related macros and functions from
crypto_types.h to crypto_values.h as the latter is
the intended file to put them in.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
