0

so I am working on a software that will have to eventually communicate with one or more servers. I am experimenting on implementing Json Web Tokens for specific parts of this communication (basically not for authentification, they will be access tokens mostly).

For some reasons, I would want to include sensitive data as a part of the payload (not highly sensitive, more like infos that are better not be shown for privacy reasons, but not critical for the application integrity).

After reading the JWE specs, and considering the available time i have to do this, i would like to spare the task of building a proper JWE for the moment, and just use a custom function to encrypt the payload before creating the JWS. A proper JWE would be then delayed until next version of the software.

Is it totally to be avoided? Can i use this as a temporary solution? Or is it rather a sign of bad desing of my communication ways?

EDIT - I preferred editing this topic, as the new question is closely related to the first one, but a bit more precise and specific:

I went on with proper security specifications and tests with it. Now that i came up with what seems to be a good encryption solution, and read quite a lot more on the subject, it seems that the approach I started to work with would be valid: it is stated in many places that encryption does not cover the content integrity, so that the message must go through a MAC (after encryption).

_So, let's take the initial question in the inverse order: now that i have a properly encrypted message, and then need to MAC it, is a JWS built with the HMAC algorithm a valid MAC? Or is it just language abuse to call it a HMAC JWS?

Kaddath
  • 5,933
  • 1
  • 9
  • 23
  • To answer this question you might want to describe which parts are you going to use or omit. JWE is not a complex standard, but the implementation will not be trivial, so my recommendation would be to use an available library. And only in case it is not available to make a partial implementation – pedrofb Jan 22 '17 at 17:14
  • Leaving aside the "obfuscation" of the interface, I do not see that KJUR supports JWE, therefore I'm afraid you'll have to implement the encryption of the content. Are you sending the tokens to other party? If they have not also a library, consider JWE it is not a good choice – pedrofb Jan 23 '17 at 13:41
  • no, i am implementing the both sides, that will not be the problem.. currently having problems to find a symmetrical encrypting solution that can (easily) decode/encode the same way on client JS / NodeJS server / PHP server, which will be mandatory part for other things. It will be enough time to find that, i'll probably drop the JWE for the moment. Thanks again! – Kaddath Jan 23 '17 at 16:06
  • edited the question instead of opening a new one, if i should have opened a new topic, please say it, thx! – Kaddath Jan 24 '17 at 13:40
  • About your additional question: To check integrityJWS applies a digital signature on the header and payload of JWT. The digital signature ensures the identity of the signer, and the content has not been altered. JWS allows to sign with a symmetric key, like HMAC, where the key to sign and verify is the same, or using a key pair (RSA). The private key is used to sign the message and verification is done with the public key. If the verification has to be done in the other side, then use a key pair and publish your public key – pedrofb Jan 25 '17 at 11:37

0 Answers0