questions on using ed25519

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

questions on using ed25519

yang berlin

Hello, I am a beginner on openssl, and I want to use the ed25519 in openssl.

The problem I met is: I can use "speed ed25519" to test the speed of ed25519, but when I use "dgst -ed25519", it tells me that "dgst: Unrecognized flag Ed25519". So could you please help me to learn how to use ed25519 correctly?

Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

Viktor Dukhovni
On Tue, Apr 21, 2020 at 05:48:19PM +0800, yang berlin wrote:

> I want to use ed25519 in openssl.

Why?  What actual real-world purpose do you have for ed25519?

> The problem I met is: I can use "speed ed25519" to test the speed of
> ed25519, but when I use "dgst -ed25519", it tells me that "dgst:
> Unrecognized flag Ed25519".

That's because "ed25519" is not a digest algorithm, it is a public key
algorithm.  You can use it to sign messages, but not to compute message
digests.

> So could you please help me to learn how to use ed25519 correctly?

That question has no answer.  Whether a use of "ed25519" is correct or
incorrect depends on the security protocol in which it is to be used,
and whether that protocol is appropriate to security requirements of
the application using it.

If you're just playing with ed25519, you can generate ed25519 keys with:

    $ openssl genpkey -algorithm ed25519 -out privkey.pem

You can extract just the public key via:

    $ openssl pkey -in privkey.pem -pubout -out pubkey.pem

You can generate an ed25519 self-signed public key certificate with:

    $ openssl req -key privkey.pem -new \
        -x509 -subj "/CN=$(uname -n)" -days 36500 -out pubcert.pem

You can use the key and certificate with s_client, and s_server
via the "-key" and "-cert" arguments.

You can also sign and/or encrypt messages with ed25519 using cms(1),
but you may not be ready to dive into cms.

Low-level public and private key operations are possible via pkeyutl(1).

While the dgst(1) command supports signing message digests with various
public key signature algorithms, ed25519 is not one of these:

       -sign filename
           Digitally sign the digest using the private key in "filename". Note
           this option does not support Ed25519 or Ed448 private keys. Use the
           pkeyutl command instead for this.

See the pkeyutl(1) manpage.

Don't assume that some use of encryption implies any gain in security.
It could be mere security theatre.  For actual security you need to
apply a robust protocol that matches the application's security
requirements.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

yang berlin
Wow, thanks for the detailed reply!
Actually I am a master student and my teacher wants me to figure out the use of ed25519. So I went to see openssl.
I thought ed25519 can sign messages so I tried the dgst command. Now I know that I was wrong.
Anyway, thank you again!

Viktor Dukhovni <[hidden email]> 于2020年4月22日周三 上午1:35写道:
On Tue, Apr 21, 2020 at 05:48:19PM +0800, yang berlin wrote:

> I want to use ed25519 in openssl.

Why?  What actual real-world purpose do you have for ed25519?

> The problem I met is: I can use "speed ed25519" to test the speed of
> ed25519, but when I use "dgst -ed25519", it tells me that "dgst:
> Unrecognized flag Ed25519".

That's because "ed25519" is not a digest algorithm, it is a public key
algorithm.  You can use it to sign messages, but not to compute message
digests.

> So could you please help me to learn how to use ed25519 correctly?

That question has no answer.  Whether a use of "ed25519" is correct or
incorrect depends on the security protocol in which it is to be used,
and whether that protocol is appropriate to security requirements of
the application using it.

If you're just playing with ed25519, you can generate ed25519 keys with:

    $ openssl genpkey -algorithm ed25519 -out privkey.pem

You can extract just the public key via:

    $ openssl pkey -in privkey.pem -pubout -out pubkey.pem

You can generate an ed25519 self-signed public key certificate with:

    $ openssl req -key privkey.pem -new \
        -x509 -subj "/CN=$(uname -n)" -days 36500 -out pubcert.pem

You can use the key and certificate with s_client, and s_server
via the "-key" and "-cert" arguments.

You can also sign and/or encrypt messages with ed25519 using cms(1),
but you may not be ready to dive into cms.

Low-level public and private key operations are possible via pkeyutl(1).

While the dgst(1) command supports signing message digests with various
public key signature algorithms, ed25519 is not one of these:

       -sign filename
           Digitally sign the digest using the private key in "filename". Note
           this option does not support Ed25519 or Ed448 private keys. Use the
           pkeyutl command instead for this.

See the pkeyutl(1) manpage.

Don't assume that some use of encryption implies any gain in security.
It could be mere security theatre.  For actual security you need to
apply a robust protocol that matches the application's security
requirements.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

Viktor Dukhovni
On Wed, Apr 22, 2020 at 11:46:16AM +0800, yang berlin wrote:

> Wow, thanks for the detailed reply!
> Actually I am a master student and my teacher wants me to figure out the
> use of ed25519. So I went to see openssl.
> I thought ed25519 can sign messages so I tried the dgst command. Now I know
> that I was wrong.

Well, actually it *does* sign messages, but not via "openssl dgst",
because typically ed25519 is used to sign short messages without first
running them through a digest function.  This makes it resistant to hash
function collion attacks.

There is actually more than one flavour of the ed25519 signature
algorithm, see RFC8032:

    https://tools.ietf.org/html/rfc8032#section-4
    https://tools.ietf.org/html/rfc8032#section-5

You can use "pkeyutl" to directly sign (short messages) with (pure)
ed25519, or, for longer messages, you can use the "prehash" variant
which signs a SHA2-512 hash.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

yang berlin
In reply to this post by Viktor Dukhovni
Hello, I checked the pkeyutl manpage, but it says that 
-The Ed25519 and Ed448 signature algorithms are not supported by this utility. They accept non-hashed input, but this utility can only be used to sign hashed input.
So what command should I use to simply sign or encrypt a message with ed25519 or x25519? I also checked the cms manpage, if I use this command the result will be in MIME format.
Besides, I used the speed command and it will test the sign and verify the speed of ed25519, I just want to know what command will do this sign and verify operation.

Viktor Dukhovni <[hidden email]> 于2020年4月22日周三 上午1:35写道:
On Tue, Apr 21, 2020 at 05:48:19PM +0800, yang berlin wrote:

> I want to use ed25519 in openssl.

Why?  What actual real-world purpose do you have for ed25519?

> The problem I met is: I can use "speed ed25519" to test the speed of
> ed25519, but when I use "dgst -ed25519", it tells me that "dgst:
> Unrecognized flag Ed25519".

That's because "ed25519" is not a digest algorithm, it is a public key
algorithm.  You can use it to sign messages, but not to compute message
digests.

> So could you please help me to learn how to use ed25519 correctly?

That question has no answer.  Whether a use of "ed25519" is correct or
incorrect depends on the security protocol in which it is to be used,
and whether that protocol is appropriate to security requirements of
the application using it.

If you're just playing with ed25519, you can generate ed25519 keys with:

    $ openssl genpkey -algorithm ed25519 -out privkey.pem

You can extract just the public key via:

    $ openssl pkey -in privkey.pem -pubout -out pubkey.pem

You can generate an ed25519 self-signed public key certificate with:

    $ openssl req -key privkey.pem -new \
        -x509 -subj "/CN=$(uname -n)" -days 36500 -out pubcert.pem

You can use the key and certificate with s_client, and s_server
via the "-key" and "-cert" arguments.

You can also sign and/or encrypt messages with ed25519 using cms(1),
but you may not be ready to dive into cms.

Low-level public and private key operations are possible via pkeyutl(1).

While the dgst(1) command supports signing message digests with various
public key signature algorithms, ed25519 is not one of these:

       -sign filename
           Digitally sign the digest using the private key in "filename". Note
           this option does not support Ed25519 or Ed448 private keys. Use the
           pkeyutl command instead for this.

See the pkeyutl(1) manpage.

Don't assume that some use of encryption implies any gain in security.
It could be mere security theatre.  For actual security you need to
apply a robust protocol that matches the application's security
requirements.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

Nicola Tuveri-2
Unfortunately at the moment the command line utilities do not support generating Ed25519 or Ed448 signatures for files.

The reason is that in OpenSSL at the moment we only support pureEd25519, which does not prehash the "message" to be signed, as Viktor mentioned before.

With other prehashed signature algorithms, signing a file is technically signing the output of some hashing function over that file, and all the common hashing functions support hashing arbitrary big data streams one chunk at a time until the full stream is consumed.
With pureEd25519, which requires the full message for the sign operation, this operation becomes more complicated as one need to buffer the whole file in memory for the duration of the operation: in absence of memory mapped files (which are not supported equally on all the platforms on which OpenSSL runs, this means that to sign e.g. a 4GB file you need to allocate a 4GB buffer in memory to load the contents of the file to be signed.
Even then, if we didn't have the portability issue of memory mapped files, supporting non-prehashed signature/verification algorithms would basically require a new dedicated tool as the current ones are strongly dependent on the assumption that signatures are computed on short hashes and that handling files can and should be done in chunks, before running the signature/verification algorithm.

As a result of these consideration the current support for Ed25519 (/Ed448) in OpenSSL is mostly dedicated to support the development of protocols using it for relatively short messages.

If you have a strong need to sign and distribute file signatures using Ed25519 keys, nothing prevents you from writing an application using the `EVP_DigestSign()` function to sign/verify an arbitrary length message stored in a buffer (possibly using memory mapped files if the platforms you want to target all support this feature to avoid unnecessary memory consumption).
As usual, pull requests are warmly welcome! So if you wanted to add support for this scenario within the openssl built-in commandline tools in `apps/` (either as a new tool or as an optional mode of operation for an existing one) it would be an interesting contribution!
As a personal suggestion, though, due to the portability problems and the controversial issue of how to handle arbitrary length files without memory mapping support for files, I would suggest opening first an issue on GitHub about it, signalling your will to contribute towards its resolution, so that solutions to these controversial problems can be discussed before committing to major development efforts.



Hope this helps,

Nicola Tuveri 



On Wed, 22 Apr 2020 at 10:22, yang berlin <[hidden email]> wrote:
Hello, I checked the pkeyutl manpage, but it says that 
-The Ed25519 and Ed448 signature algorithms are not supported by this utility. They accept non-hashed input, but this utility can only be used to sign hashed input.
So what command should I use to simply sign or encrypt a message with ed25519 or x25519? I also checked the cms manpage, if I use this command the result will be in MIME format.
Besides, I used the speed command and it will test the sign and verify the speed of ed25519, I just want to know what command will do this sign and verify operation.

Viktor Dukhovni <[hidden email]> 于2020年4月22日周三 上午1:35写道:
On Tue, Apr 21, 2020 at 05:48:19PM +0800, yang berlin wrote:

> I want to use ed25519 in openssl.

Why?  What actual real-world purpose do you have for ed25519?

> The problem I met is: I can use "speed ed25519" to test the speed of
> ed25519, but when I use "dgst -ed25519", it tells me that "dgst:
> Unrecognized flag Ed25519".

That's because "ed25519" is not a digest algorithm, it is a public key
algorithm.  You can use it to sign messages, but not to compute message
digests.

> So could you please help me to learn how to use ed25519 correctly?

That question has no answer.  Whether a use of "ed25519" is correct or
incorrect depends on the security protocol in which it is to be used,
and whether that protocol is appropriate to security requirements of
the application using it.

If you're just playing with ed25519, you can generate ed25519 keys with:

    $ openssl genpkey -algorithm ed25519 -out privkey.pem

You can extract just the public key via:

    $ openssl pkey -in privkey.pem -pubout -out pubkey.pem

You can generate an ed25519 self-signed public key certificate with:

    $ openssl req -key privkey.pem -new \
        -x509 -subj "/CN=$(uname -n)" -days 36500 -out pubcert.pem

You can use the key and certificate with s_client, and s_server
via the "-key" and "-cert" arguments.

You can also sign and/or encrypt messages with ed25519 using cms(1),
but you may not be ready to dive into cms.

Low-level public and private key operations are possible via pkeyutl(1).

While the dgst(1) command supports signing message digests with various
public key signature algorithms, ed25519 is not one of these:

       -sign filename
           Digitally sign the digest using the private key in "filename". Note
           this option does not support Ed25519 or Ed448 private keys. Use the
           pkeyutl command instead for this.

See the pkeyutl(1) manpage.

Don't assume that some use of encryption implies any gain in security.
It could be mere security theatre.  For actual security you need to
apply a robust protocol that matches the application's security
requirements.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

Viktor Dukhovni
On Wed, Apr 22, 2020 at 01:27:03PM +0200, Nicola Tuveri wrote:

> Unfortunately at the moment the command line utilities do not support
> generating Ed25519 or Ed448 signatures for files.
>
> The reason is that in OpenSSL at the moment we only support pureEd25519,
> which does not prehash the "message" to be signed, as Viktor mentioned
> before.

Which means no support in dgst(1), but that manpage suggests pkeyutl(1),
which e.g. for RSA supports signing raw (unhashed input), but 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.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

Nicola Tuveri-2
I have to correct myself, in `master` (and very soon in the 3.0.0 alpha1 release) `pkeyutl` already has support for sign/verify files with Ed25519 keys.

```
λ /tmp/test25519/ ### Ensure OpenSSL dev build is in use for this shell
λ /tmp/test25519/ which openssl ; openssl version
/opt/openssl-master/bin/openssl
OpenSSL 3.0.0-dev xx XXX xxxx (Library: OpenSSL 3.0.0-dev xx XXX xxxx)
λ /tmp/test25519/ ### Generate Ed25519 private key
λ /tmp/test25519/ openssl genpkey -algorithm Ed25519 -out priv.pem
λ /tmp/test25519/ ### Extract pub key from private key
λ /tmp/test25519/ openssl pkey -in priv.pem -pubout -out pub.pem
λ /tmp/test25519/ ###
λ /tmp/test25519/ ### Up to this point all the commands were compatible
λ /tmp/test25519/ ### with OpenSSL 1.1.1 releases, the next one is the
λ /tmp/test25519/ ### one that requires OpenSSL 3.0.0-dev as `pkeyutl`
λ /tmp/test25519/ ### now has support for `-rawin` which is required
λ /tmp/test25519/ ### for signing/veryfing files with Ed25519 keys.
λ /tmp/test25519/ ###
λ /tmp/test25519/ ### Generate a signature `sig.dat` for the file
λ /tmp/test25519/ ### `/bin/ls` using `priv.key` private Ed25519 key;
λ /tmp/test25519/ openssl pkeyutl -sign -inkey priv.pem -out sig.dat \
    -rawin -in /bin/ls
λ /tmp/test25519/ ### Verify the file `/bin/ls` against a signature
λ /tmp/test25519/ ### `sig.dat` under the public Ed25519 key `pub.pem`.
λ /tmp/test25519/ ### Success is expected.
λ /tmp/test25519/ openssl pkeyutl -verify -pubin -inkey pub.pem \
    -rawin -in /bin/ls -sigfile sig.dat
Signature Verified Successfully
λ /tmp/test25519/ ### Verify the file `/bin/echo` against a signature
λ /tmp/test25519/ ### `sig.dat` under the public Ed25519 key `pub.pem`.
λ /tmp/test25519/ ### Failure is expected.
λ /tmp/test25519/ openssl pkeyutl -verify -pubin -inkey pub.pem \
    -rawin -in /bin/echo -sigfile sig.dat
Signature Verification Failure
```

On Wed, Apr 22, 2020, 19:12 Viktor Dukhovni <[hidden email]> wrote:
On Wed, Apr 22, 2020 at 01:27:03PM +0200, Nicola Tuveri wrote:

> Unfortunately at the moment the command line utilities do not support
> generating Ed25519 or Ed448 signatures for files.
>
> The reason is that in OpenSSL at the moment we only support pureEd25519,
> which does not prehash the "message" to be signed, as Viktor mentioned
> before.

Which means no support in dgst(1), but that manpage suggests pkeyutl(1),
which e.g. for RSA supports signing raw (unhashed input), but 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.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

Matt Caswell-2
In reply to this post by Viktor Dukhovni


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.

Matt
Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

Nicola Tuveri-2
On Thu, 23 Apr 2020 at 11:02, Matt Caswell <[hidden email]> 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

Nicola

Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

Viktor Dukhovni
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.
Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

Nicola Tuveri-2
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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

yang berlin
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 <[hidden email]> 于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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: questions on using ed25519

Nicola Tuveri-2
The change in itself is quite trivial, just editing the dgst manpage to remove the reference to pkeyutl.

The issue has more instructions and the idea was to use it as a way to let a new developer familiarize with OpenSSL contributing guidelines and process.

Another user already started working on it, though! 

If anyone is interested we have more "good first issue" items on github that we considered a good starting point for users from the community that are willing to start contributing to the project by coding or working on the documentation. 


Nicola 

On Sun, Apr 26, 2020, 04:01 yang berlin <[hidden email]> wrote:
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 <[hidden email]> 于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 <[hidden email]> 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.