Python implementation of the Javascript Object Signing and Encryption (JOSE) framework

There's a bug in the way the authentication tag is computed, running all tokens issued by the library undecipherable by other libraries, since they will always fail to check the token authentication if there's authenticated data (note that for compact serialization, the header should always be authenticated).

When computing the authentication tag, first we need to concatenate the data authenticated, the IV, the ciphertext and the length of the authenticated data in 64 bits big-endian. This is the input to the HMAC algorithm that yields the authentication tag. However, the values are concatenated in the _jwe_hash_str() method using a period between them, which is against RFC7518.

This PR addresses the problem by removing the period, using just an empty string as glue for the concatenation. In order to keep backwards compatibility and still be able to decrypt old tokens, the legacy mode of _jwe_hash_str() is kept as is. The temporary version number has been increased to 2, so that all new tokens are encrypted with the correct authentication tag, while all the tokens issued before this change can still be identified and decrypted in legacy mode.

The issues, according to the JWA spec are:

• the AL field is not correctly calculated. It must represent the length in bits of the additional authenticated data, not in bytes. Additionally, it must be represented as an unsigned 64-bit octet string in big-endian, not as a simple string.

5.2.2.1.4. The octet string AL is equal to the number of bits in the additional authenticated data A expressed as a 64-bit unsigned big endian integer.

• in order to compute the authentication tag, the ciphertext must be used, not the plaintext.

5.2.2.1.5. A message authentication tag T is computed by applying HMAC [RFC2104] to the following data, in order:

•     the additional authenticated data A,
  

•     the initialization vector IV,
  

•     the ciphertext E computed in the previous step, and
  

•     the octet string AL defined above.
  

• in AES_CBC_HMAC_SHA2, the length of the input key equals to the digest size, that being 32, 48 and 64 octets for each of the three variants.

The AES_CBC_HMAC_SHA2 parameters specific to AES_128_CBC_HMAC_SHA_256 are:

•  The input key K is 32 octets long.
  

• ENC_KEY_LEN is 16 octets.
  

•  MAC_KEY_LEN is 16 octets.
  

• the integrity key and encryption key are derived as the first and second half of the input key, respectively.

The secondary keys MAC_KEY and ENC_KEY are generated from the input key K as follows. Each of these two keys is an octet string.

•     MAC_KEY consists of the initial MAC_KEY_LEN octets of K, in order.
  

•     ENC_KEY consists of the final ENC_KEY_LEN octets of K, in order.
  

The number of octets in the input key K MUST be the sum of MAC_KEY_LEN and ENC_KEY_LEN. The values of these parameters are specified by the Authenticated Encryption algorithms in Sections 5.2.3 through 5.2.5. Note that the MAC key comes before the encryption key in the input key K; this is in the opposite order of the algorithm names in the identifier "AES_CBC_HMAC_SHA2".

import jose

  File "/py/env35/local/lib/python3.5/site-packages/jose.py", line 546
    print decrypt(deserialize_compact(jwt), {'k':key},
                ^
SyntaxError: invalid syntax

Is this package compatible with python 3.5?

decrypt chooses decrypt method (legacy or spec-compliant) using exceptions. In this commit special treatment for failures due to expiration is added. If token decryption failed due to expiration we do not want to try the other decryption method. In addition we no longer miss expiration exceptions in such cases.

I see there is a 1.0 version in setup, but no release on pypi? I'm interested in using this library, but would like to see some of the fixes in place first. Any update on when 1.0 will become available? Great work by the way.

Hi,

Unless I am missing something, there's nothing in the JOSE JWE drafts saying that the plaintext used for JWE encryption must be a JSON object, nor that it must be json-encoded. Both the encrypt and the decrypt methods assume that the input must be a dict, and json-encode/decode it, making it difficult to deal with cases when you just want to encrypt a simple string. Even though we can just pass a string as a parameter and get it encrypted in the resulting JWE, this poses interoperability issues when using other libraries. If we use the example in the JWE draft, we can generate a JWE like this:

jwe = jose.encrypt('The true sign of intelligence is not knowledge but imagination.', pub_jwk)

If we then decrypt this with this library, we will get the same string. However, if we use a different library, we will get the string json-encoded, like:

"The true sign of intelligence is not knowledge but imagination."

Note the double quote signs. This is a problem because then we need to json-decode the plaintext, even though we didn't encode it when calling jose.encrypt()!

I think the best approach is to assume the plaintext to be a string, and then it is up to the user to json-encode it if he or she wants to use a JSON object. Besides, the claims jargon is confusing, and very tied to the windows world. Most people not using this library for something related to windows will be confused and won't know what's that about, specially given that claims are not mentioned at all in the JOSE drafts.

Thanks in advance!

Have mostly adapted the jose package to work with python 3 (in addition to python 2).
Getting tests running with multiple versions of python has necessitated rearanging some of the files but I believe that I have managed to avoid breaking the current api.

There is one remaining problem which is that I can't figure out what format the key for hmac algorithms should be in and therefore whether, and where, it should be encoded as bytes or unicode. Will have another look at fixing it now. This problem does not affect python 2 however.

I do have to say that the excellent test suite has made this really quite easy. Thank you.

Package versions in Python packages (especially libraries) should not be pinned down. Two specific reasons why jose shouldn't do it:

1. It doesn't look like it uses any specific functionality of version pycrypto 2.6. On the other hand it causes serious compatibility problems: pkg_resources.VersionConflict: pycrypto 2.6.1 is installed but pycrypto==2.6 is required by ['jose']
2. pycrypto 2.6.1 fixes an important security bug.

Please merge and upload new package to PyPI. Thanks :)

Will jose support python 3? I have been changing code to work on both 2 and 3 simulteanously since 2014, I can help you if you like.

Our tests currently stop on the print in cli_decrypt().

By changing the print to print() and adding "from future import print_function" jose'll work on python 2.6.0a2 and newer. If you replace the print with sys.stdout.println it'll work everywhere it works today. But since at least your travis only tests 2.7, I'd recommend print-the-function, and setting 2.7 in your setup.py.

Python3 gives an error when importing this module. Error message shown below:

File "/usr/local/lib/python3.7/site-packages/jose.py", line 546
    print decrypt(deserialize_compact(jwt), {'k':key},
                ^
SyntaxError: invalid syntax

Hi, I am looking for a way to verify the source of a content, in JSON format, that is sent to my application written in react native. I was wondering if this package is working fine with RN?

Thanks

On Ubuntu 18.04 with Docker for Python 3.6.8, the RUN pip3 install --trusted-host pypi.python.org -r requirements.txt command fails with message:

Collecting jose (from -r requirements.txt (line 1))
  Downloading https://files.pythonhosted.org/packages/01/3d/832caa69cd0d3be2d608d8290be2221072669aa88e87690837f6b31c480f/jose-1.0.0.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-build-z90crgu0/jose/setup.py", line 15, in <module>
        CONTRIB = open(os.path.join(here, 'CONTRIB')).read()
      File "/usr/lib/python3.6/encodings/ascii.py", line 26, in decode
        return codecs.ascii_decode(input, self.errors)[0]
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 107: ordinal not in range(128)

File "/usr/local/lib/python3.6/site-packages/jose.py", line 546 print decrypt(deserialize_compact(jwt), {'k':key}, ^ SyntaxError: invalid syntax

Python3's own json-library refuses to serialize the result of serialize_compact() since it is not a py3 str but a py3 bytes. This breaks our code, at the least. I'm not sure about the best way to solve it. A flag that sets encoding and if set spits out str and not bytes? Doing another walkthrough throught the code and choosing when to use str vs. bytes instead of always using bytes? Add to the json-library upstream so that it can serialize bytes, assuming that you tell it the encoding to use?

Anyway, the documentation for the function says it returns str, which it does not do on python3.