Combining JWE and JWS

Question

Just learning about JOSE and I understand that JWE is for encryption and JWS is for signing. What I don't seem to be able to find examples of is a payload that is both encrypted and signed.

Let's pretend I have a payload hello world. Is the correct thing to do something like this? JWS(JWE('hello world') with the encrypted JWE as the payload of the JWS?

Craigie

Yes this is correct, but the order is important. You should first sign, then encrypt (JWE(JWS(payload))). See tools.ietf.org/html/rfc7519#section-11.2 for details. – Heligoland

@Heligoland what if the requirement tells us encrypt first then sign ?please help me with this query as my vendor has given me first encrypt then sign process – Sandon

This is fine as well. Technically correct and allowed by the specification. Is see 2 main issues with JWS(JWE(payload)). 1) the JWS can completely be removed and replaced by another (malicious) one. 2) JWS header is visible and may leak information. – Heligoland

@Heligoland actually they done some java code at their end and i am doing encryption and decryption in PHP so i am facing some issue . I have created token from your package but there is no option in your package like this JWS(JWE(payload)) do i hve to done it manually? or do i have to opt nested token – Sandon

github.com/web-token/jwt-nested-token/blob/v3.0/… sjould help you. It is only JWE(JWS(payload)) but JWS(JWE(payload)) is pretty straightforward – Heligoland

Answer 1

JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWT is a generic name for the following types of token:

• JSON Web Signature (JWS): The payload is encoded and signed so the integrity of the claims can be verified.

• JSON Web Encryption (JWE): The payload is encrypted so the claims are hidden from other parties.

^{The image was extracted from this page.}

---

Is the correct thing to do something like this? JWS(JWE('hello world') with the encrypted JWE as the payload of the JWS?

It's a nested JWT and its concept is defined in the RFC 7519:

A JWT in which nested signing and/or encryption are employed. In Nested JWTs, a JWT is used as the payload or plaintext value of an enclosing JWS or JWE structure, respectively.

You could add a JWE as a claim of a JWS payload, however the other way around is recommended: First sign the message and then encrypt the result, as mentioned in the same document:

11.2. Signing and Encryption Order

While syntactically the signing and encryption operations for Nested JWTs may be applied in any order, if both signing and encryption are necessary, normally producers should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.

Mcdougal

I see– I was under the impression JWT was usually used for auth. If I wanted to encrypt an entire paragraph and send that as a JSON payload is JWT still the appropriate way to do this? – Craigie

It is preferable to sign first then encrypt (see The order is important. You should first sign, then encrypt. See tools.ietf.org/html/rfc7519#section-11.2 for details) – Heligoland

@FlorentMorselli That's the quote I was looking for :) – Mcdougal

Answer 2

You should pay attention when you talk about sign or encrypt in case of asymmetric keys.
let's suppose that you want to send your token from producer to consumer.
Sign and encrypt shall be done with different key pairs.
You must sign with the producer private key
AND
You must encrypt with the consumer public key
SO
--> consumer MUST have the possibility to get the CORRECT public key of producer to check signature, this generally must be done with getting a certificate and validating this certificate by validating the chain of trust. Once the certificate is valid use its public key.
--> in the same way, PRODUCER MUST have a valid certificate of the consumer for the encryption.

To be more secure, I think what is described in specification is not sufficient for the general case: JWK(JWS('hello world!')) imply that your consumer must decrypt systematically all incoming messages to know the identity of sender. So, because the world can know consumer's public key in general, an attacker can try a DoS attack by sending a high burst of large encrypted messages. So to filter them an additional MAC using the private key of sender is good, or, exchange everything in a secure mutual authenticated TLS tunnel...

Selfexcited