Hi Bob,
On Thu, Mar 7, 2024 at 12:49 AM Bob Wolff bob.wolff68@gmail.com wrote:
Hey all, I'm not opposed to using the kernel ecdsa.c and have taken a quick look at `ecdsa_verify()` - but I'd love if someone could point me in the right direction for how to set up the context and public key. The akcipher_request structure seems to address both the signature and the digest, but I am not seeing how to take my public key data and get it involved. Any examples of usage, possibly? Doing several google searches did not bear fruit for me.
Thanks, bob
I'd start with the image_sign_info/image_region structs definitions in [1] and examples of how they are both filled in RSA signature verification tests in [2], as ecdsa_verify() also uses them.
Then I would extend the existing ECDSA dummy test in [3] by adding some test public key data in DER format, data and encrypted hash of this data, like it's done in [2], so you have the way to test your own UCLASS_ECDSA driver implementation.
And obviously the existing ST UCLASS_ECDSA driver might be a good reference [4].
Hope this helps!
[1] include/image.h [2] test/lib/rsa.c [3] test/dm/ecdsa.c [4] arch/arm/mach-stm32mp/ecdsa_romapi.c
On Wed, Feb 28, 2024 at 10:57 PM Dan Carpenter dan.carpenter@linaro.org wrote:
On Thu, Feb 22, 2024 at 03:07:01PM -0800, Bob Wolff wrote:
Peter, Thanks for helping lead me down the right path here.
WRT tinycrypt, the license is quite permissive. https://github.com/intel/tinycrypt
Also, I'd like your advice - I was thinking for the larger patch that
I'd
do it in two commits. The first would be the addition of the tinycrypt files and the second is the actual changes and additions to support
ecdsa
verification. I doubt that's controversial. However when I run a trial `patman` against the tinycrypt commit, I geta huge number of issues: *checkpatch.pl http://checkpatch.pl found 186 error(s), 380 warning(s), 481 checks(s)*
What's your advice on this? I would tend to think we'd want to /not/
change
the source files directly for such purposes so that updates could be brought in with greater ease.
Yeah. For this kind of thing you wouldn't want to make a bunch of checkpatch changes. They sometimes pull crypto and compression libraries into the Linux kernel pretty much unmodified as well for the same reason.
Igor's proposal about pull this stuff from the Linux kernel instead seems like a good idea though.
regards, dan carpenter