# Can I use the secret part of a asymmetric encryption keypair as a symmetric encryption key?

### Background

I'm working on a framework for crypto-based authentication and authorization that is largely inspired by the way Keybase's Teams product works.

Keybase uses the same process to generate per-user keys and per-team keys. Quoting their docs:

1. A user generates a 32-byte random seed s.
2. She computes e = HMAC(s, "Keybase-Derived-Team-NaCl-EdDSA-1") and uses this value as the secret key for an EdDSA signing key. She then computes the public half, yielding keypair (E, e).
3. She computes d = HMAC(s, "Keybase-Derived-Team-NaCl-DH-1") and uses this value as a secret key for a Curve25519 DH encryption key. She then computes the public half, yielding keypair (D,d).
4. Computes c = HMAC-SHA256(s, "Derived-User-NaCl-SecretBox-1") and uses this value as a symmetric secret key.

In brief:

1. Make a random seed, and use it to generate
2. A signature keypair
3. An asymmetric encryption keypair
4. A symmetric key

### Question

I was thinking that to simplify things, I could skip step 4 and reuse the asymmetric encryption secret key d as the symmetric key, instead of deriving an additional key c. In practice, if you know one, you'll know the other. All else being equal, I'd prefer to have fewer moving parts.

Is there a reason not to do this?

(To be clear, my system doesn't need to interoperate with Keybase - I'm just using their process as a model.)

• So you give a private key to the other site. Not a good idea. Keep them separated. Not instead of HMAC, one can use HKDF to derive the keys, too – kelalaka May 28 at 9:31
• ? A keyset consists of a signature keypair (secret + public), an asymmetric keypair (secret + public), and a symmetric key (secret). So the question is whether the symmetric secret is necessary, or if I can just use the asymmetric secret for both purposes. – Herb Caudill May 28 at 9:57

Let's start with the statement "In practice, if you know one, you'll know the other.". This is incorrect. The KDF construction uses a one way function so that you cannot get to the input keying material (or seed) s. This means that if an adversary gets hold of the symmetric key c that you cannot calculate either s and therefore e or d.
There is another more theoretical problem in the sense that using d both for HMAC as for "symmetric secret key" then you're using the same value for multiple algorithms, breaking their security claim. It might be that there is some mathematical algorithm that makes the value of s vulnerable. From a practical perspective that's highly unlikely as a HMAC with a known string will not be a structure that can be abused for this kind of attack - but I think it is worth mentioning anyway. For instance, an auditor may ask nasty questions about it.