Open LiamK opened 4 years ago
The encryption is designed so that only the application layer is capable of decrypting the data. This means that when dumping or replicating your database, the data is never exposed.
Maybe I didn't explain that correctly. Normally when accessing the field, it is decrypted at the application layer. In this case, I'm not dumping or replicating the database. I'm transferring data from one database to another database. Thus, it would advantageous and better security to leave the data encrypted. The databases must share the same key, of course.
If there were a way to retrieve/store the data without automatically applying decryption/encryption it would make things easier. As it is, I must transmit it as plain text, or retrieve the data as plaintext, encrypt it myself, and then decrypt it myself and store it on the other end, or make a direct SQL query, transmit the encrypted data, and again make a direct SQL insert on the other end.
I ended up doing the latter.
Now I understand what you are asking. You wish to know some of the inner workings to bypass the layers of abstraction. The way the field stores the information in the database is using Django's BinaryField
. This allows for a raw stream of bytes to be passed and stored into the database field.
CharField
|
\ /
[ encrypt ]
|
\ /
PickledField
|
\ /
BinaryField
The above diagram shows the layers of what is happening underneath the hood. Encrypt strips the normal Django field of its data, but uses the fields constraints and functionality. It then replaces the field with a PickledField
that can serialize the raw python value. The pickled data is then passed to the encryption algorithm and stored in a BinaryField
.
I used this ticket to add documentation about this.
@LiamK If you want to access the encrypted data then i think you should use Django-CryptographicFields
Is there any way to access the encrypted data? I need to move it between systems, and it seems safer to keep it encrypted while in transit, and then insert it directly in the new system (which must have the same key, of course). I could work around this by making an extra raw SQL query, but that seems like an awful way of doing it.