# (Non)security of algebraically derived EC keys

I recently had a situation where I needed to derive a secondary Curve25519 private key from an existing one programmatically. The obvious solution was to use a KDF, but I wondered at the time about deriving the second key via some algebraic operation on the scalar value, which of course would (at least for some transformations) also make the secondary public key derivable from the original public key. My default assumption was that this would not be safe, possibly giving a way to solve for the original (and derived) private key using the two public keys. Is this correct? If so, what would the key recovery look like?

My default assumption was that this would not be safe, possibly giving a way to solve for the original (and derived) private key using the two public keys. Is this correct?

Actually, it is fairly easy to show that it is not correct.

Suppose we have a public key $$H$$ based on the private key $$k$$ (so $$H=kG$$, where $$G$$ is the curve generator) and we derive a secondary private key $$k' = ak+b$$ (for public $$a, b$$), and a derived public key $$H' = k'G$$. Suppose further that we have an Oracle that, given $$H, H'$$ (and $$a, b$$), was able to recover the $$k$$.

Then, what we could do, given $$H$$, is compute the derived public key $$H' = aH+bG$$, and hand $$H, H'$$ to our Oracle, and it'll give us the private key.

That is, because it can be computed publicly means that it can't cause leakage (at least, not in the way you're worrying about)

• Thanks. Are there other ways it could cause leakage outside of what I had in mind? Aug 20, 2021 at 22:03
• Possibly, depending on how you use the private keys. I don't see one immediately for EdDSA, though... Aug 20, 2021 at 22:04
• Context here is ECDH, which I think would be less susceptible to any such issues than signing would be. Aug 20, 2021 at 22:09
• That formula makes me think of SEC#4 implicit certificate. Aug 21, 2021 at 10:19