ECDSA related PRs

[Bob Wolff]

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

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
>
>