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:
- A user generates a 32-byte random seed
s
.- 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)
.- 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)
.- Computes
c = HMAC-SHA256(s, "Derived-User-NaCl-SecretBox-1")
and uses this value as a symmetric secret key.
In brief:
- Make a random seed, and use it to generate
- A signature keypair
- An asymmetric encryption keypair
- 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.)