Are you using Ed25519 + X25519 for asymmetric encoding?

I am creating a public key cryptosystem (just for fun, I don’t roll my own crypto!) That can create identities, which are just Ed25519 + RSA-OAEP key pairs. I want an identity to be able to sign messages and receive encrypted messages. My public identities are large, mainly because of the RSA-OAEP public key, which I am a bit dissatisfied with (I want identities to be personally shared via QR codes, so short length is a plus). This got me thinking … Can I also reuse Ed25519 + X25519 for the asymmetric encoding? If Alice creates a static DH key pair and shares her DH public key (signed, as part of her identity) then Bob can calculate a shared secret and use it for symmetric encryption (sending his short-lived DH public key along with the message). But this, of course, means that Alice’s DH secret is static and will be reused for many senders. Is this a safe thing to do, or should DH key pairs always be ephemeral? (If this is healthy I probably reinvented something, does this schema have a name?) What are the implications of this schema over RSA-OAEP? One difference I see is that Bob can decode the cyphertext … which he produced himself, so I’m not worried about that! Are there any other implications that I have missed? Thanks!

About is a news websites which gets news around the globe on investing in Crypto. Our news has no backgroundcheck.

4 thoughts on “Are you using Ed25519 + X25519 for asymmetric encoding?”

  1. If you have an Ed25519 signature key, you can use it to sign X25519 ephemeral keys as part of an authenticated key exchange.

    The details of how to do that are a bit tricky though, especially with X25519 as there are a number of solutions (both zero and a set of low order points) for which the D-H function will output zero.

    You’ll either want to use a SIGMA-like protocol like Noise (e.g. the XX pattern with the signature extension), or a protocol like STROBE/Merlin which computes a transcript of the key exchange and fails if there is any disagreement between the peers.

  2. x25519 is out of the box capable of hybrid asymmetric encryption just as you described it. that’s a perfectly valid use case.

    on the other hand, you can always choose public keys to be 256 bit. all you need to do is to redefine the public key as sha256(pubkey), and redefine signature as (pubkey, signature).

    the old wisdom says: if you really want, all signature schemes have a private key of 128 bits, and a public key of 256 bits.

  3. You want static ephemeral Diffie-Hellman where you use the recipient’s static public key, generate an ephemeral key pair, use its private key for the DH computation to get Z, run a KDF on it, use the result to wrap the content’s encryption key, then send the recipient the wrapped key and the ephemeral public key.

    For details, see NIST SP800-56a, the CMS RFCs, etc.


Leave a Comment