ECDSA related PRs

[Igor Opaniuk]

Hi Bob,

On Thu, Mar 7, 2024 at 12:49 AM Bob Wolff <bob.wolff68 at 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 at 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.opaniuk at gmail.com
skype: igor.opanyuk
http://ua.linkedin.com/in/iopaniuk