2
$\begingroup$

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

Improve this question
$\endgroup$
2
  • 2
    $\begingroup$ 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 $\endgroup$
    – kelalaka
    May 28, 2020 at 9:31
  • $\begingroup$ ? 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. $\endgroup$
    – Herb Caudill
    May 28, 2020 at 9:57

1 Answer 1

Reset to default
7
$\begingroup$

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.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Re: "In practice, if you know one, you'll know the other." - I should have been clearer. What I meant is that in this implementation you're always given a keyset as a unit. So if I've been given the asymmetric keypair, I've also been given the symmetric key. $\endgroup$
    – Herb Caudill
    May 28, 2020 at 11:12
  • 3
    $\begingroup$ I second the: don't. When we consider side-channel attacks (Timing, DPA, DEMA…), key separation becomes a practical issue. There's the possibility that an attack of a key under use by the implementation of one algorithm succeeds and reveals the key used for another algorithm. And much worse, there is a reasonable possibility that a combined attack on the two implementations of the two algorithms succeeds, when either implementation would have not been broken. Indeed, I think a Common Criteria auditor would not immediately rubber-stamp the idea of sharing the key directly, for that reason. $\endgroup$
    – fgrieu ♦
    May 28, 2020 at 12:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.