Sure, I can help. It's my pleasure to help with the project. Since you have opened an issue. Then what should I do?
Nicola Tuveri <nic....@gmail.com> 于2020年4月24日周五 下午11:17写道： > 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 > > > On Thu, 23 Apr 2020 at 19:33, Viktor Dukhovni <openssl-us...@dukhovni.org> > 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. >> >
