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

Question

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.)

Answer 1

The HMAC calculation is used as a KDF here. So 3 keys are derived.

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.

From a more practical point there may be an issue when it comes to side channel attacks. If these can be combined then there may be a practical issue when the keys are not separated (this is of course a blatant copy of the comment by fgrieu below).

And that's about it; the reason to separate the keys is key separation itself. If you want to break that rule then that's your decision, but it is certainly not considered good cryptographic practice. I'd only do such tricks if there is no other way.