SECRET_KEY is still used for some calculations even if CRYPTOGRAPHY_KEY is set

[Glenn Matthews]

Per the documentation,

CRYPTOGRAPHY_KEY
Default: None
When value is None a key will be derived from SECRET_KEY. Otherwise the value will be used for the key.

This documentation is incorrect, or at least incomplete. I can confirm that even when CRYPTOGRAPHY_KEY is set, some calculations still use SECRET_KEY. This can be demonstrated by populating some encrypted fields, then changing SECRET_KEY - a BadSignature error will be reported on trying to access the fields, but changing SECRET_KEY back to its old value will restore normal operation.

[Glenn Matthews]

In other words, once you begin using this library, you may never change SECRET_KEY again, even if you're defining CRYPTOGRAPHY_KEY as the documentation recommends.

[Eric Smith]

Duplicate of #37?

[Roman Gorbil]

Faced the same issue.
Steps to reproduce:

1. Start new project, install django-cryptography, set both SECRET_KEY and CRYPTOGRAPHY_KEY
2. Add at least 1 instance of model with encrypted field
3. Change value of SECRET_KEY

Expected result: encrypted fields may be decrypted as CRYPTOGRAPHY_KEY wasn't changed
Actual result: BadSignature because encryption key changed.

[Richard Shea]

FWIW I've just attempted to replicate this issue and with ...

Django==4.2.11
django-cryptography==1.1

.... the dependency on SECRET_KEY is still the case.

Just doing a PR to reflect the situation in the documentation.