Skip to content

Refactor t_cose_crypto_is_algorithm_supported in PSA - #297

Open
gaborgvarga wants to merge 1 commit into
laurencelundblade:devfrom
gaborgvarga:is_algorithm_supported
Open

Refactor t_cose_crypto_is_algorithm_supported in PSA#297
gaborgvarga wants to merge 1 commit into
laurencelundblade:devfrom
gaborgvarga:is_algorithm_supported

Conversation

@gaborgvarga

Copy link
Copy Markdown

Replacing static allowlist with runtime checks.

Previously, the PSA crypto adapter layer used a hard-coded allowlist, which could report algorithms as supported even when the crypto backend did not enable them. This refactor changes
t_cose_crypto_is_algorithm_supported to query the PSA crypto backend at runtime, ensuring capability checks reflect actual algorithm support.

Change-Id: I51a11b1018f50a5f874d8fbd4412a8b9ac1a16e6

@gaborgvarga
gaborgvarga force-pushed the is_algorithm_supported branch from 8b7fc28 to fdff057 Compare September 26, 2025 12:06
@gaborgvarga

Copy link
Copy Markdown
Author

Hi @laurencelundblade,

When you get a chance, would you mind reviewing this PR?

Thank you,
Gabor

Replacing static allowlist with runtime checks.

Previously, the PSA crypto adapter layer used a hard-coded allowlist,
which could report algorithms as supported even when the crypto backend
did not enable them. This refactor changes
t_cose_crypto_is_algorithm_supported to query the PSA crypto backend at
runtime, ensuring capability checks reflect actual algorithm support.

Signed-off-by: G. Varga, Gabor <Gabor.G.Varga@arm.com>
Change-Id: I51a11b1018f50a5f874d8fbd4412a8b9ac1a16e6
@gaborgvarga
gaborgvarga force-pushed the is_algorithm_supported branch from fdff057 to f285b54 Compare October 8, 2025 11:18
@laurencelundblade

Copy link
Copy Markdown
Owner

Hi Gabor, I'm finally getting back to some t_cose work.

Can you tell me the reason for this change? What problems is it trying to solve. I think I know, but I want to be sure.

Thx

@gaborgvarga

Copy link
Copy Markdown
Author

Hi @laurencelundblade,

Sure, the goal is to avoid false positives from the PSA crypto adapter.

Previously, t_cose_crypto_is_algorithm_supported() in the PSA layer relied on a static allowlist, but in practice algorithm availability is backend config dependent. In those cases the allowlist could report “supported”, and then the actual operation can later fail with PSA_ERROR_NOT_SUPPORTED. That makes capability reporting unreliable and pushes the failure further down the flow.

Best,
Gabor

@laurencelundblade

Copy link
Copy Markdown
Owner

Thanks, Gabor,

I agree that this is a really good thing to do.

I have some trouble with this PR because it is kind of big and complicated. In particular, it takes is_algorithm_supported from a tiny function, to very large. Large both in the object code for the function itself and large because it pulls in a huge amount of MbedTLS. It breaks the general decoupling between different classes and types of algorithms. Most people won't use it, but one call to is_algorithm_supported and your code size might more than double.

The question I have is whether there are better ways to accomplish this. It is a perfectly good and reasonably things to do. PSA/MbedTLS shouldn't make it this complicated. I also worry about the complexity to support this.

I think MbedTLS does have a better way, but then we'd be outside the PSA API.

Thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants