decoder memory-management question

[D. J. Bernstein]

I wrote:
> I'm planning similar X25519 integration.

That turned out to not take long (see attached) as a fork of the Ed25519
provider. Merging the providers would have taken slightly more work. I
don't know how well OpenSSL scales with the number of providers.

On Haswell, this bumps `openssl speed ecdhx25519` up from 21123.0 op/s
to 29652.0 op/s, and produces even bigger speedups in key generation
(not shown by `openssl speed`). This could also be tweaked to support
batch key generation as in engntru and eng25519. Batch DH could be done
with a separate thread.

Caveats from my previous message apply. These providers could easily
have serious problems. Some OpenSSL features that would help build
confidence would include a much simpler provider API, positive and
negative tests for the API, and a clear memory-management discipline.

---D. J. Bernstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl_x25519_lib25519.c
Type: text/x-csrc
Size: 22571 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20240302/a7fdb33d/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.sh
Type: application/x-sh
Size: 2778 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20240302/a7fdb33d/attachment-0001.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20240302/a7fdb33d/attachment-0001.sig>