1

We want to use token for some services (which we own and develop) and we are considering to implement JWE or Paseto.

Token and payload should be encrypted (some string or json).

What is benefit of using JWE or something rather than just encrypting payload with some algorithm and use it as a token?

rkj
  • 784
  • 1
  • 8
  • 19
  • @SergioTulentsev thx for correcting me. I've edited question. – rkj Feb 07 '22 at 17:32
  • Why are you using a token instead of a session? Often this choice is driven by multiple services using the same token. Multiple services implies multiple implementations. If you use a standard for the token, supported by libraries for different platforms, you are likely to get better security with less effort than you would with a homebrew scheme. Is that along the lines of what you are looking for? – erickson Feb 07 '22 at 17:43
  • We want to use token because it will be used in different services, platforms which are independent. We will not implement our own encrypting algorithms. Idea is use HS512 for example, just like python jose implementation is using it, so nothing is homebrew. We just do not see any benefit of using JWE, since its actually using RSA or HMAC with SHA in the end. – rkj Feb 07 '22 at 17:52
  • Your response isn't clear. Are you saying that you will be using the same algorithms, but the output will not be formatted and encoded as a JWE? Because that is still homebrew. The cryptographic algorithms are going to work correctly, no doubt about that; but there are a million and one things to get wrong *in the application* of those algorithms. And now you need to implement it multiple times, amplifying your exposure. Do you actually want an answer to this question? Or are you just looking for some justification to commit to a decision you've already made? – erickson Feb 07 '22 at 17:59
  • To simplify, what is more easier and what could get more wrong than using some well known symmetric algorithm implementations like https://stackoverflow.com/a/41888765/1107750 for example? What does JWE token have "more" and why is better that this Fernet encoded text? – rkj Feb 07 '22 at 18:13
  • So essentially token allows for REST and similar API calls where the state is not maintained live. This allows you to not spend server resources while your client is requesting something from time to time. In regards to why is JWE 'better' -> this is dealer's choice. It's well understood and there are good implementations to work with it in most modern frameworks, that's the advantage. It is secure enough. Can you achieve the same by rolling your own? absolutely. Can you shoot yourself in the foot multiple times while reinventing the wheel? most definitely. – zaitsman Feb 10 '22 at 11:38

1 Answers1

0

Why is JWE better than just encrypting content/payload with RSA/HMAC?

HMAC would be "signing" (not technically I know) but it's not encryption, it's ensuring integrity and authenticity. RSA in the context of JOSE would be either public key encryption key management (encryption for a recipient using a "wrapped" random content encryption key) to achieve confidentiality, or digital signatures (integrity and authenticity but not confidentiality).

What using either of the protocols will do over just barebones encryption is that it ensures you won't end up with unauthenticated encryption. JOSE and PASETO always ensure integrity in their used cipher (or combination of ciphers).

You can find plenty of polarizing opinions on PASETO and JOSE, in the end it boils down to what you prefer for your service.

You can achieve everything PASETO can do with JOSE. PASETO has public tokens (signed) using RSASSA-PSS, ECDSA, and EdDSA - JOSE does too. PASETO has local (symmetrically encrypted) tokens using AES and XChaCha - JOSE does too (former always, latter not yet registered and widely supported).

OTOH you cannot achieve everything JOSE can do with PASETO. JOSE supports encryption for a recipient using their public key. PASETO on its own does not - that's what PASERK, an independent - rather new protocol with very lacking library support, from the authors of PASETO, is for.

It sounds like what you want to do is symmetric encryption. Using either of the two protocols it boils down to whether you want cryptographic agility (JOSE) or not (PASETO) and whether there's existing library/module to use for the languages you intend to use.

I've implemented both JOSE and PASETO in their (almost) full specification for javascript runtimes.

Edit covering the comments in the original questions:

We just do not see any benefit of using JWE

The benefit is confidentiality. A signed payload anyone can decode and read. An encrypted one only the intended recipient can. You should make up your mind whether you want just authentic and integrity protected tokens (that's JWS or public PASETO) or confidential ones (that's JWE or local PASETO).

  • 1
    If we want to use symmetric encryption, what does JOSE and PASETO symmetric encryption implementations offer more than just to encrypt/decrypt payload with some symmetric encryption? At the end both will use symmetric encryption or something. Will they not? – rkj Feb 07 '22 at 18:20
  • I apologize I was not clear, I have made mistake in the title. I meant AES, symmetric encryption. I want to use confidential tokens. – rkj Feb 07 '22 at 18:24
  • 1
    Interoperability. Rather than having to write your proprietary logic in every single consumer application the ability to pick up a module that understands JWE or PASETO off the shelf is the benefit. Plus knowledge that whatever cipher suite it uses below the cover was vetted by professionals in the space as well as years of use. –  Feb 07 '22 at 18:27
  • 1
    On top it's, at least in most libraries, automatic processing and validation of claims for expiration, token audience(s), issuers, etc. –  Feb 07 '22 at 18:27
  • 1
    Plus, some level of crypto agility, without needing to update every consumer application you ought to be able to distribute new keys for an updated PASETO version / JOSE algorithm and the applications, given you chose an algorithm supported in the used libraries, will not need any additional changes. –  Feb 07 '22 at 18:37
  • Never ever use symmetric encryption with your web tokens. Symmetric encryption basically means 'whoever has the keys to validate authenticity can also use them to forge their own tokens'. Always implement an STS of sorts to issue RSA or ECDSA signed tokens and only distribute your PUBLIC keys to validate. – zaitsman Feb 10 '22 at 11:35
  • @zaitsman that is circumstantial, not always the case. In the OPs case, he explained they both the issue and consume the tokens and wish for the token's contents to be confidential. No other mechanism than symmetric encryption fits that use case. –  Feb 10 '22 at 12:01
  • @FilipSkokan even if you both issue and consume the tokens you should still designate an isolated application as the issuer and have all your other applications only consume. This way you have one central location to work on if things are compromised, and you can control necessary access to that private key (e.g. most likely nobody needs to have that access). Of course, I am talking in a commerical software. For a homegrown project you can do whatever you want. – zaitsman Feb 10 '22 at 12:04