-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sys/psa_crypto: sha3 support #20698
sys/psa_crypto: sha3 support #20698
Conversation
Cool! Could you clean up your commits? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! 🎉
Some rather minor suggestions for improvement below. Please add them first in separate commits and only squash/rebase after we've had a look at the new changes.
sys/psa_crypto/include/psa_hashes.h
Outdated
#if IS_USED(MODULE_PSA_HASH_SHA_3) || defined(DOXYGEN) | ||
/** | ||
* @brief Low level wrapper function to call a driver for a SHA3-256 hash setup | ||
* See @ref psa_hash_setup() | ||
* | ||
* @param ctx | ||
* @return psa_status_t | ||
*/ | ||
psa_status_t psa_hashes_sha3_256_setup(psa_hashes_sha3_ctx_t *ctx); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to have different psa modules for SHA3-256/384/512 or is the increase in code size if including all three per default negligible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mguetschow The increase in code-size is indeed negligible since they are all based on the same keccak-code (which is the biggest part of the underlying code), which needs to be compiled anyway with every variant of the sha3 algorithm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, then it sounds reasonable to me to keep it as is. But maybe @Einhornhool has a different opinion and would argue in favor of consistency with the SHA-2 PSA modules?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, for consistency it would be better to separate them. BUT we separated the SHA-2 modules for the purpose of being modular, since some hardware backends we saw only supported SHA-256 and we wanted to be able to build software backends for the others.
As far as I can see there's only one implementation for SHA-3 available (RIOT Hashes) which supports all three variants. So there's no need to build two different backends.
For me it would be totally fine to keep them together for now and only separate them once we integrate a backend that does not support all of them.
It would be good to document this, though.
Update: Just checked again and there are some other libraries with SHA-3 support. HACL also supports 256/384/512 and Cifra additionally supports 224. I don't see a reason to mix different software backends, though, so I think separation is only needed once we get a hardware accelerator that only supports a subset of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think separation is only needed once we get a hardware accelerator that only supports a subset of them.
but that would be an API change then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered this and I agree. This would be an API change, which makes it more prone to errors.
Also it would require people who add drivers in the future to not only add wrappers, but also to change the module structure.
That makes it less friendly to develop.
I'm sorry for changing my mind now, but I think it would be better to keep the structure consistent with the other modules :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your fixups, I'm now happy with the changeset! You may rebase and squash everything together in one or two commits (in case you want to split implementation + test in separate commits).
5b947ca
to
d1b8c2e
Compare
7a4d388
to
f56cc83
Compare
f56cc83
to
9b50202
Compare
@mguetschow done :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, nice work!
Contribution description
This PR adds a new pseudomodule for using the existing sha3-hashings-algorithms in a simpler way.
More specific: It adds gluecode for the PSA Crypto API to access the RIOT implementation of SHA3.
Testing procedure
The corresponding tests are located in tests/sys/psa_crypto_hashes/example_sha3_glue.c
You can run them the following way:
Issues/PRs references
N/A