CODEWITHSUNDEEP
public-key-encryptionjwtauth0
Whee
Whee

Reputation: 269

How do JWTs Implement Public-key Cryptography?

This actually breaks down into a lot of separate questions to understand the overall process.

  1. From what I understand a JWT is just three JSON objects encoded into base64 separately from one another. Then the Base64 strings are separated by periods. This is done purely for "shorter message" purposes?

  2. These include a header, "payload," and signature. The header and payload are 100% available to read by anyone who intercepts them. They are just base64 strings that can be decoded into JSON and read.

  3. Then the MAGIC: The server receives the SIGNATURE, which cannot be decoded. The signature is actually a hash of the header, payload, AND a secret key. So the server takes the header, the payload, and ITS OWN secret key, and makes a hash. If this hash MATCHES the signature that came with the message, the message is trusted. If the signatures DO NOT match, the message is invalid.

My problem with all this? Where are the two separate keys here? It seems that the key used to encrypt the message and the key used to decrypt the message are the same. This is the root of my question - if you answer nothing else, please help with this.

Other than that, I wonder if I understand the process correctly? Also, where is the standard "agreeing on a public key" and then trading "mixtures" of public/private keys occurring here? All I see is the same key being used to encode/decode. But when did the agreement happen? Viewing this in context of .NET and Auth0 btw, but overall q.

Random stuff I watched/read/used if anyone is interested on seeing this q later:

Summary of JWTs: https://scotch.io/tutorials/the-anatomy-of-a-json-web-token

Public-key/Assymetric Cryptography: https://youtu.be/3QnD2c4Xovk

Hashing: http://www.webopedia.com/TERM/H/hashing.html

Base64: http://en.wikipedia.org/wiki/Base64

Upvotes: 5

Views: 896

Answers (2)

frasertweedale
frasertweedale

Reputation: 5694

  1. Then the MAGIC: The server receives the SIGNATURE, which cannot be decoded. The signature is actually a hash of the header, payload, AND a secret key. So the server takes the header, the payload, and ITS OWN secret key, and makes a hash. If this hash MATCHES the signature that came with the message, the message is trusted. If the signatures DO NOT match, the message is invalid.

There is no magic here. JWT supports four well-known signature and MAC (message authentication code) constructions: HMAC (a symmetric algorithm), and ECDSA, RSASSA-PKCS-v1.5 and RSASSA-PSS (public-key algorithms). Each of these may be used with the SHA-256, SHA-384 or SHA-512 cryptographic digest. See also the table of Cryptographic Algorithms for Digitial Signatures and MACs from RFC 7518 - JSON Web Algorithms (JWA).

My problem with all this? Where are the two separate keys here? It seems that the key used to encrypt the message and the key used to decrypt the message are the same. This is the root of my question - if you answer nothing else, please help with this.

There are not necessarily two separate keys - if a public key algorithms is used, the signature will be created using the server's private key, and verified using the corresponding public key. But if an HMAC algorithm is used, a shared secret key must be used for both signing and verification.

Upvotes: 3

Hans Z.
Hans Z.

Reputation: 54118

Firstly, JSON Object Signing and Encryption standards (JOSE) use base64url encoding and not straight base64 encoding, which differs slightly.

  1. JWT header and payload are JSON objects but the signature is not, that's a base64url encoded binary blob

  2. the whole JWT is available to anyone who intercepts it, all 3 parts of it

  3. you're describing a symmetric key algorithm, where sender and receiver use the same shared key; that is just one option for JWTS, another option is to use public/private key pairs for signing/validation/encryption/decryption

As with all crypto, agreement on keys needs to happen out of band.

Upvotes: 3

Related Questions