georgemarshall / django-cryptography

Easily encrypt data in Django

Home Page:https://django-cryptography.readthedocs.io/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Signature version not supported is raised on attempt to access encrypted data from the other instance of the app

anton-kazlouski opened this issue · comments

I faced with a problem of decrypting data on my local machine.
Basic queryset lookup raises the following exception when fetching data that was encrypted on a remote server (stage).
BadSignature: Signature version not supported

On the remote server I don't have any issues with accessing that encrypted data.
Locally I'm using the same keys: both CRYPTOGRAPHY_KEY and SECRET_KEY as in stage.
I can't be sure for 100% with CRYPTOGRAPHY_KEY as it modified by CryptographyConf, however bytes representation is the same on both instances.

Previously it worked fine, I have no idea what could break it. The interesting thing is that, the following code worked on the stage, but it doesn't now:

from django_cryptography.utils.crypto import FernetBytes
fernet = FernetBytes(key='super-secret-that-no-one-can-guess')
import pickle
from django.db import connection
with connection.cursor() as cursor:
    cursor.execute(
        'SELECT little_secret from cia_secret_data where name = "agent_007"'
    )
    res = cursor.fetchone()
pickle.loads(fernet.decrypt(res))

It produces the same error as above.
I was trying to figure out what's going on in /django_cryptography/core/signing.py but unfortunatelly too dumb for this.

Not sure if there is a problem with my setup or this a bug of the django-cryptography.

django-cryptography==1.1
Django==3.2.13

I have added some debug code into CryptographyConf.configure to capture the actual key and can confirm that keys are the same on both instances.

When I'm connected to the staging database the error I'm getting is different:

BadSignature: Signature "b'J9O/UECSKzgMgggjUkDckkBKQcA5bbtYi7RLqP/Z5pA=\n'" does not match

I guess my problem relates to this one:
#37

The problem was on my side, caused by incorrect data export.
For those who probably will face with the same issue, here is how to export with mysqldump:
mysqldump --result-file="" db_name --complete-insert --skip-extended-insert --hex-blob

The key here is to use --hex-blob. Also, I had to add --complete-insert --skip-extended-insert.