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
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 <yangbolinzju@xxxxxxxxx> 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 <openssl-users@xxxxxxxxxxxx> 于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.
