PSA 1.2 compliance #560

New issue

Open

opened 2025-11-04 05:06:03 -06:00 by dbuenzli · 3 comments

dbuenzli commented

2025-11-04 05:06:03 -06:00

(Migrated from github.com)

I recently finished and published thin bindings to the tfpsacrypto C library for the OCaml programming language (docs). These bindings were made by following the PSA 1.2 specification. Thus I noticed that a few macros and entry points were missing in tfpsacrypto.

These omissions can be found by searching for 'Not in TF-PSA-Crypto 1.0.0' in this source but I'm happy to follow up with the concrete list in this issue or in one issue per kind of operation, according to your wish. If you think this is covered elsewhere (I couldn't find a clear issue though) then you can also just close this.

I recently finished and published thin bindings to the `tfpsacrypto` C library for the OCaml programming language ([docs](https://erratique.ch/software/bytesrw/doc/Bytesrw_crypto/Psa/index.html)). These bindings were made by following the PSA 1.2 specification. Thus I noticed that a few macros and entry points were missing in `tfpsacrypto`. These omissions can be found by searching for 'Not in TF-PSA-Crypto 1.0.0' in [this source](https://github.com/dbuenzli/bytesrw/blob/89e1d04f40743386886503a388b0d7f6300ae3c4/src/crypto/bytesrw_crypto__psa_stubs.c) but I'm happy to follow up with the concrete list in this issue or in one issue per kind of operation, according to your wish. If you think this is covered elsewhere (I couldn't find a clear issue though) then you can also just close this.

gilles-peskine-arm commented

2025-11-04 06:29:50 -06:00

(Migrated from github.com)

We tend to not define macros for algorithms that we don't implement. (Defining the macros is trivial in itself, but in some cases it has a non-trivial impact on our test scripts: we have test scripts that enumerate all declared mechanisms, and we have to add exceptions if something is actually not implented.) For TF-PSA-Crypto (and Mbed TLS before it), you can check whether a specific mechanism is implemented through PSA_WANT_xxx preprocessor symbols.

There are a few missing functions, and there are no preprocessor guards for that. Off the top of my head, I think the only missing ones are hash suspend/resume, and some newer PAKE functions that are used for SPAKE2+ but not for EC-JPAKE. Your annotations “Not in TF-PSA-Crypto 1.0.0” seem to confirm this. We could provide trivial implementations for the few missing functions that just return NOT_SUPPORTED.

Compliance to the PSA Certified Crypto API (the formal name) does not require implementing the whole API. The API is intended especially for constrained devices where it is expected that only part of the API is available. TF-PSA-Crypto implements a large subset of the API, but not everything. We tend to not define macros for algorithms that we don't implement. (Defining the macros is trivial in itself, but in some cases it has a non-trivial impact on our test scripts: we have test scripts that enumerate all declared mechanisms, and we have to add exceptions if something is actually not implented.) For TF-PSA-Crypto (and Mbed TLS before it), you can check whether a specific mechanism is implemented through [`PSA_WANT_xxx` preprocessor symbols](https://github.com/Mbed-TLS/TF-PSA-Crypto/blob/tf-psa-crypto-1.0.0/docs/proposed/psa-conditional-inclusion-c.md). There are a few missing functions, and there are no preprocessor guards for that. Off the top of my head, I think the only missing ones are hash suspend/resume, and some newer PAKE functions that are used for SPAKE2+ but not for EC-JPAKE. Your annotations “Not in TF-PSA-Crypto 1.0.0” seem to confirm this. We could provide trivial implementations for the few missing functions that just return `NOT_SUPPORTED`.

gilles-peskine-arm commented

2025-11-04 06:32:31 -06:00

(Migrated from github.com)

It's not really clear to me what the scope of this issue is. If it's to support everything that's listed in the PSA specification, then no, we're definitely not going to do that. If it's to have linkable versions of every function, that's doable. If it's to declare every macro, that's also doable but a little more complicated due to the impact on our test coverage checks.

dbuenzli commented

2025-11-04 06:56:20 -06:00

(Migrated from github.com)

I think the problem are these. As user of the library:

Am I coding against the PSA Certified Crypto API or am I coding against the TF-PSA-Crypto implementation?
How do I discover upfront what is not implemented by TF-PSA-Crypto?

If the answer to 1. is coding against the specification then I would like these things to be available at compile time along with clear documentation about 2.

Regarding:

If it's to have linkable versions of every function, that's doable. If it's to declare every macro, that's also doable but a little more complicated due to the impact on our test coverage checks.

I'd say that from the perspective of bindings to the API from other languages you likely want that. Having variable entry points/macros brings in all sorts of problems. And the idea is that the binding should be reusable across PSA Certified Crypto API implementations.

I think the problem are these. As user of the library: 1. Am I coding against the PSA Certified Crypto API or am I coding against the TF-PSA-Crypto implementation? 2. How do I discover upfront what is not implemented by TF-PSA-Crypto? If the answer to 1. is coding against the specification then I would like these things to be available at compile time along with clear documentation about 2. Regarding: > If it's to have linkable versions of every function, that's doable. If it's to declare every macro, that's also doable but a little more complicated due to the impact on our test coverage checks. I'd say that from the perspective of bindings to the API from other languages you likely want that. Having variable entry points/macros brings in all sorts of problems. And the idea is that the binding should be reusable across PSA Certified Crypto API implementations.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#560

No description provided.

Rows
Columns