questions on using ed25519

[Nicola Tuveri]

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 <yangbolinzju at gmail.com> 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 at dukhovni.org> 于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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200422/ad7ac632/attachment-0001.html>