0

Currently I'm building a Rails API using ruby-jwt as my access token generator. I choose RS256 (RSA + SHA256) as my algorithm.

ruby-jwt uses private key to encode payloads, and uses public key to decode tokens.

My question is, is this approach secure enough? Is there any chance that an attacker can exploit the private key from a large amount of tokens? Why doesn't it use public key to encode and private key to decode?

Aetherus
  • 103
  • 3

1 Answers1

2

When you speak about making "claims", this is exactly how it's done. A private key is not meant to be distributed. The keeper of the key is the authentic user of the key. It allows them to issue authentic claims. If that key were ever compromised, then other claims could be made that would be accepted as authentic. In other words, whoever has the private key can impersonate an authorized oracle.

The public key, on the other hand, is meant to be distributed to all servers that should trust the owner of the private key. This key doesn't allow anyone to make claims, but it allows everyone to acknowledge that the claim is indeed true. Other technologies, such as SAML, use a similar technique: the issuing server holds a private certificate, and the relying parties use that server's public certificate to verify the assertion.

For what it's worth, there's nothing special about the public and private keys. You could swap them around after they're generated but before the public key were distributed, and it would work in the same way. And, technically, yes, since JWT has a documented format, you do know what the payload is supposed to look like, which would weaken the key security a bit, but it still doesn't really help you, since each bit in a key affects multiple bits. It would be very hard to use a chosen plain-text attack against even a large number of tokens, simply because of the large number of bits that are used. Remember, the goal of recovering the private key isn't to get at the decrypted data (because the public key is already available), it's how to impersonate a given server.

phyrfox
  • 5,724
  • 20
  • 24
  • 1
    Are you sure you can swap the public and private keys in RSA? I don't think that's secure – Neil Smithline Jun 12 '16 at 16:40
  • @NeilSmithline Given keys A and B, where each are half of a pair generated by the algorithm, messages encrypted with A can only be decrypted by B, and messages encrypted by B can only be decrypted by A. It is a two way communication. Until you choose which key you keep private, and which you share, there is no distinction between the two keys. In fact, this is how TLS works. Each side sends a public key, which the other uses to encrypt a private message (which in turn is used in a shared symmetrical key). This only applies to asymmetric encryption. – phyrfox Jun 12 '16 at 22:58
  • I do not think this is the case for RSA specifically, though I am not certain. I will research. I any case, it doesn't really change the correctness of your answer – Neil Smithline Jun 12 '16 at 23:00
  • 1
    It seems to be a bad idea to share the private key and keep secret the public key http://stackoverflow.com/q/696472/721263 – Neil Smithline Jun 12 '16 at 23:06
  • I agree with @NeilSmithline. The public and private keys are not interchangeable. It doesn't make sense to encrypt with the private key. There is signing, however this is a distinct algorithm, although people tend to inaccurately describe this as "encrypting with the private key". – SilverlightFox Jun 13 '16 at 07:50
  • The public and private keys definitely are NOT interchangeable. Most software, such as openssl, choose a predictable exponent for the public key for efficiency. If you have such a private key, you can compute the public key. – Jim Flood Jan 03 '18 at 08:44