Crypto knowledge: up to PSA Crypto 1.4, XOF test driver #265
No reviewers
Labels
No labels
approved
bug
dependencies
DO-NOT-MERGE
enhancement
good-first-issue
help-wanted
historical-reviewed
historical-reviewing
needs-adoption
needs-ci
needs-design-approval
needs-info
needs-preceding-pr
needs-review
needs-reviewer
needs-work
priority-high
priority-low
priority-medium
priority-scheduled
priority-very-high
single-reviewer
size-l
size-m
size-s
size-xs
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-Mbed-TLS/mbedtls-framework!265
Loading…
Reference in a new issue
No description provided.
Delete branch "crypto_knowledge-psa_spec_1.4-no_pake"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Add support for things that will be needed for ML-DSA: key type, algorithm, and also XOF category support for SHAKE. Needed for https://github.com/Mbed-TLS/TF-PSA-Crypto/pull/683 and https://github.com/Mbed-TLS/TF-PSA-Crypto/issues/633.
I've also added support for other mechanisms to
generate_psa_tests.py, covering most of what is in version 1.4 of the API including the PQC extension. There are two exceptions for key data: PAKE keys (too fiddly, might need extra work to cut down on the curves), and stateful hash-based signatures (no format defined for key pairs). I have some local testing that suggests that these are the only exceptions, but it's far from being in a reviewable state, and not particularly important.Status: ready.
PR checklist
A few initial questions
Will this work with all versions of mbedtls ie. if there is no PAKE in the version will this error?
@ -455,16 +489,20 @@ class Algorithm:"""return short_expression(self.expression, level=level)Is there a bit/byte mismatch here. All the other entries appear to be bytes and PSA_ALG_SM3 looks like it could be bits?
No, it wouldn't. That's preexisting, out of scope, and not important since we aren't planning to remove PAKE. What's more problematic, but also preexisting and out of scope, is that this excludes PAKE from systematic testing of operation failure, even if we add support for it in a branch. But I really don't want to get into the complexity of PAKE on the way to implement something completely different.