Conversion from Ed25519 to Curve25519 public keys

[chrysn]

Keys used for EdDSA can conceptually be converted to Curve25519 keys usable for static-static key derivation.

This mechanism is being specified for Group OSCORE (draft-ietf-core-oscore-groupcomm-10):

If EdDSA asymmetric keys are used, the Edward coordinates are mapped
to Montgomery coordinates using the maps defined in Sections 4.1 and
4.2 of [RFC7748], before using the X25519 and X448 functions defined
in Section 5 of [RFC7748].

A concrete use case where it would be convenient to have the conversion is the aiocoap library, which implements Group OSCORE and uses OpenSSL through the cryptography Python library. If OpenSSL exposed the conversion, cryptography could do so too (as tracked in issue pyca/cryptography#5557). Until that works, aiocoap needs to pull in libsodium (or, as currently being explored, other libraries for manual manipulations of curve points) as an additional dependency just to perform that single conversion.

The conversion itself is not particularly hard for a cryptographic library:

• For converting a secret key, it's running SHA512 once, truncating the hash and and then twiddling a few bits); applications can implement that manually with relative ease.
• For converting a public key, it's doing a few curve operations; programs building on OpenSSL are likely not inclined to do any of that manually, especially given that the necessary functions are not exposed by OpenSSL.

Please consider adding a function to convert EVP_PKEY_EC keys from ED25519 to X25519.

I think I can put this together as a pull request, but I'd need some initial guidance as to which level this would be exposed on (having a name this could have might already help).

[kaduk]

Keys used for EdDSA can conceptually be converted to Curve25519 keys usable for static-static key derivation.

This mechanism is being specified for Group OSCORE (draft-ietf-core-oscore-groupcomm-10):

Thank you for bringing this to my attention; as described, it is likely to get a DISCUSS ballot if it remains in the document at time of IESG Evaluation. I will go comment on that document.

(In case it's not clear, I don't think OpenSSL should add this functionality, since it encourages use of a single key for multiple different algorithms, which is bad cryptographic hygeine.)

[chrysn]

There has been progress (accessible on 1) on showing that there are cases when joint security can be achieved for these cases (which AIU also influences pending updates to the group-oscore key derivation steps).

With that in mind, would such an addition to OpenSSL be viable? It sure would need warning signs in the documentation, possibly worded along the lines of "This must only be used if it for the given application joint security of both curve points has been shown; 1 describes one way of doing that". But now there is concrete indication of how to use it safely, and a case that builds on that.

[kaduk]

I expect that this will be the sort of thing where we'll want to wait until an RFC or similar standard that actually uses the technique is published, before we'd merge the code to do it. But it's also the sort of thing where we could review/comment on a PR earlier than that.

[tmshort]

libsodium provides this functionality via crypto_sign_ed25519_pk_to_curve25519() and sk equivalent.

[xicilion]

I wrote a patch to implement this conversion.
#23884

[nhorman]

Theres a patch available in a discussion, just needs someone to propose it as a PR, marking as a community effort