1

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?

c_idle
  • 183
  • 6
  • I believe, Tink specifically has methods for serializing and parsing keyset material. Depending on the primitive, you can already use the private key to retrieve the public key or may need to have access to some additional randomness used during key generation. But I am not sure the latter is very common. – Marc Ilunga Mar 15 '24 at 10:13

1 Answers1

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.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • Interesting. I just noticed that when using X25559 it can seemingly be derived, but if i use another kem, then it does not. Thank you for the excellent response. – c_idle Mar 14 '24 at 20:02
  • You're welcome. But please note that the best way of saying thanks on [se] is to upvote and / or accept the answer. That way the other users can also see that the question has been answered sufficiently - besides the rep gained of course. – Maarten Bodewes Mar 14 '24 at 22:01
  • @MaartenBodewes-modelection, would you have a reference for that? I am probably missing something but, why can't we solve $e = 1/d \mod \phi (N) $. Or the equivalent with Carmichael? – Marc Ilunga Mar 15 '24 at 16:36
  • @MaartenBodewes-modelection, in just run some sagemath code, and it's rather efficient to do. I started by generating a large $e$ about 2000 bits, and the corresponding primes. Now, in the spirit of the question we have both $d, and \phi(N)$ as one would have upon exporting the secret key. From there, computing pow(d, -1, phi) in sagemath is quite efficient and recovers e without issue. Am I missing something, can you expand on what you mean by finding without a starting point in your previous comment? – Marc Ilunga Mar 16 '24 at 09:15
  • Ah, I see where I went wrong. Yes, if you have access to the private exponent or the primes (i.e. the private key) then getting to $e$ is sufficient. The old way of creating the key pair by first choosing $e$ still relies on computing $d$ to establish the key pair as of course the public and private key need to be linked directly. The required primes are usually included with the private key as CRT parameters but they can otherwise be calculated from the private exponent. More info in the second section of this answer – Maarten Bodewes Mar 16 '24 at 16:24