Andrew Thoelke
Andrew Thoelke
The Crypto API currently only supports importing a key where the caller specifies the key type. The required format for the key is typically just the key value itself. There...
`psa_crypto_init()` is allowed to, and even encouraged to, initialize the RNG. This allows many implementations to provide a RNG that will never fail. (Implementations that comply to some security standards...
Add an API to indicate if a key can be guaranteed to have never been exposed outside of its security boundary. This is required to enable PSA key attestation. The...
Now that the PAKE Extension is Final, and is subject to the same future compatibility requirements as the rest of the Crypto API, it should be incorporated into the primary...
In updating the attestation specification for the PSA Attestation Token report format, and given the elapsed time since v1.0, it is worth reviewing and refreshing the use cases described in...
Aligning with the other APIs, the Attestation API needs an SRA. In this case, there is little to be said about the API itself, other than requiring implementations to be...
In version 1.1, the Crypto API encodes key types according to [*Appendix B.2*](https://arm-software.github.io/psa-api/crypto/1.1/appendix/encodings.html#key-type-encoding). For asymmetric keys, this allocates 4 bits for an 'ASYM-TYPE' value, and 7 bits for a 'FAMILY'...
## Use case There are some systems in which there is a requirement for asymmetric cryptographic operations in execution contexts that cannot tolerate long-running functions. However, some asymmetric operations have...
The Crypto API already has definitions for the SM3 hash algorithm and a SM4 block cipher key type. #22 proposes the addition of support for SM2, a set of elliptic...
The Crypto API already has definitions for the SM3 hash algorithm and a SM4 block cipher key type. CSTC also defines the SM2 public-key algorithms for digital signature, key exchange,...