That's right! Thanks Viktor for pointing that out!!
I just opened an issue to track this: https://github.com/openssl/openssl/issues/11633
We warmly welcome contributions from everyone and this could be a good first issue to work on: Yang (as the person that started this thread and noticed the issue first) or anyone else from the community, are you willing to get your hands dirty and help out the project?
Nicola
I just opened an issue to track this: https://github.com/openssl/openssl/issues/11633
We warmly welcome contributions from everyone and this could be a good first issue to work on: Yang (as the person that started this thread and noticed the issue first) or anyone else from the community, are you willing to get your hands dirty and help out the project?
Nicola
On Thu, 23 Apr 2020 at 19:33, Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote:
On Thu, Apr 23, 2020 at 11:23:35AM +0200, Nicola Tuveri wrote:
> > On 22/04/2020 18:12, Viktor Dukhovni wrote:
> > > sadly the
> > > EVP_PKEY_METHOD for ed25519 has a NULL sign() member, instead, somewhat
> > > ironically, it has a digestsign() method. This is presumably to
> > > distinguish between the pure and prehash variants. Therefore, presently
> > > pkeyutl(1) indeed appears to not implement signing and verifying with
> > > ed25519, this looks doable with modest effort.
> >
> > I'm fairly sure it used to have a "sign" function during the dev phase -
> > but it was taken out. I forget the reasoning.
>
> Yes, that change was intentional, the reasoning is detailed in the
> discussion in: https://github.com/openssl/openssl/pull/6284
This did leave us with a documentation bug, the dgst(1) manpage suggests
using pkeyutl(1) for ed25519 and ed448, but the latter does not work.
The dgst(1) manpage probably needs a tweak to remove the misleading
redirect. Or else backport the pkeyutl(1) support from 3.0, but we're
not supposed to add features in 1.1.1x patch releases, and there are no
plans for a 1.1.2.
--
Viktor.
