1

. . . Or is that discouraged, and it's better to use separate key pairs for TLS and JWT? (It would be slightly easier to manage one key pair only, but probably better security to use two separate key pairs).

Crowdpleasr
  • 125
  • 4
  • 2
    The problem is that they have fundamentally different security requirements. For example, there is no need for the client to need to check web of trust for JWTs. Also, if doing JWT by HMAC (or a similar scheme that isn't based on asymmetric cryptography), one also doesn't need to have a public/private keypair with a mathematical relationship between them. Just need a long enough random key to feed into the algorithm and choose a good hashing algorithm. – ewanm89 Oct 30 '19 at 22:48
  • Thank you. That must be why for TLS the public key seems to be part of the Certificate (to cover web-of-trust). I'm new to this, but the example I'm following suggests using an RSA key-pair for JWT. So assuming I choose to use RSA for JWT, it looks as though I'd indeed need to generate a key pair that's separate from TLS keys. Thank you! – Crowdpleasr Oct 30 '19 at 22:56
  • Well personally, I probably wouldn't use RSA myself due to efficiencies of using asymmetric cryptography mathematics, that said, unless one is generating a lot of tokens, it shouldn't be that critical. That said it does depend on some other factors such as how you are using them. – ewanm89 Nov 01 '19 at 14:59

1 Answers1

1

No, don't do this. This is related to the "never roll your own crypto" rule: understanding all the math in the algorithms and all the implementation details is very hard, and there is a high chance you will miss something leading to vulnerabilities. Also just because you can't break your design, it doesn't mean no one else can.

There is a great question on crypto.SE about using the same RSA keypair to sign and encrypt, and the answerers conclude that even though theoretically it could be done securely, in practice it will very likely lead to vulnerabilities:

Therefore, it is technically safe, cryptographically speaking, to use the same RSA key pair for signature and encryption, provided that the key pair is used safely for signature and used safely for encryption. Here, I mean safe in a narrow sense, assuming a “perfect” world where everything that should stay secret, remains secret.

The thing is, the world is not perfect. Implementations of RSA can leak partial information through side channels. Keys get compromised. Protocols using RSA sometimes use it in ways that are very brittle.

Using the same key for both encryption and signature can exacerbates weaknesses. RSA has a history of weaknesses, not in the mathematical algorithm itself (once you use proper padding), but in the way it's implemented.

Your situation is slightly different (although TLS can use RSA keys for encrypting the session key, and JWT uses the key to sign the payload), but this shows that using the same key for multiple purposes can lead to unintended consequences.

Also as ewanm89 pointed out in the comments: the two use-cases have fundamentally different security requirements and different key management (e.g. how do you rotate your keys and how often do you do that, for how long would you accept JWTs signed with the old key etc.).

Torin42
  • 281
  • 1
  • 3