Hi Bob, On Thu, Mar 7, 2024 at 12:49 AM Bob Wolff <bob.wolf...@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.carpen...@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 > > > > > -- Best regards - Atentamente - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk http://ua.linkedin.com/in/iopaniuk