Using HPKE, if I generate my key pair can I derive the public key from the private key just in case I lose the public key?

Question

Hypothetically, if I am using tink-java and I generate a keyset/keypair. If I lost my public key, can I get the public key from the private key?

Answer 1

TL;DR Usually the underlying problem of the asymmetric primitive used is structured in such a way that a public key can be derived from the private key. However, there is no requirement for any key pair generation function to have this property, and it may require direct access to private key component and - of course - the required code to do so.

---

The issue is that from the RFC 9180 covering HPKE we can see the problem with the question from a quote directly in the abstract clause:

HPKE works for any combination of an asymmetric KEM

The public key generation is specific the KEM function. These functions are generally specified as a set of $\text{Gen}, \text{Enc}, \text{Dec}$ where $\text{Gen}$ is the generation of the key pair.

Fortunately the main algorithm that is shown is (EC)DH. For ECDH over the P-curves the solution is relatively simple, as the public key $P$ is simply $P = G^S$ where $S$ is the private key. It's the same for key pairs for X25519 and the X448 although an additional clamping operation needs to be performed.

Higher end API's may not directly expose a function to derive a pubic key from a private key. It is however possible to hack them if you've got access to "raw" ECDH (i.e. ECDH without the key derivation function that follows it), as that implements $P'^S$ where $P'$ is the public key from the other side, so you might be able to simply put in $G$ instead. Or you could implement or borrow the public key derivation function from existing source of course.

Clamping is a simple bit-wise operation, so it should be easy to implement / borrow.

---

Otherwise the answer depends on the underlying computational problem of the algorithm used, and how the $\text{Gen}$ function operates. If we'd assume RSA-KEM then most likely the exponent is one of the smaller exponents, usually the value 0x010001. As the modulus is part of the private key (which, in many encodings, actually contains the public exponent) it would be easy to come up with the public exponent.

However if it is large then you'd have to perform mathematical operations that may not be directly exposed within a cryptographic library designed to do RSA only (see below in the comment section), and that is assuming that you have direct access to the required components of the private key.

RSA-KEM is not provided as KEM though in this RFC, so chances are small that it will be expanded to that. The main contenders would be PQC algorithms and/or a hybrid construction based on both ECDH and PQC, but you'll have to create a separate question for that, as those are also absent from the RFC.