Hello,

I just have a general question. To check if encryption works I had a look on the database tables and found out that this module saves encrypted data in it's own "field_encrypt" table. Here in the column "value" an array is saved which includes the encrypted value, the encryption method and the key name. The key name here is not the same key name which is saved under the settings (admin/config/system/encrypt). So I have the following questions:

1.) Is there another key used? If yes: where is it saved? or is the saved key name in field_encrypt table just a kind of synonym?
2.) I would think it might be more secure if I do not save the name of the key and the encryption method with the encrypted value to make it more complicated to decrypt the value. I am not an encryption specialist but I would think people who want it to decrypt might be very thankful for every hint telling them how the encrypted values was encrypted?!

Thank you in advance for your response!

Best,
Tobias

Comments

Deciphered’s picture

Project: Field Encryption » Encrypt
Version: 7.x-1.0-beta2 » 7.x-2.x-dev

This is a question for Encrypt, not Field Encryption.

rlhawk’s picture

Tobias -

1) I'm not entirely sure what you mean by the key name being different from what was chosen in the settings. The key provider name that gets stored with the encrypted data is the machine-readable name, as distinct from the human-friendly label. If you choose a different key provider later in settings, the data will continue to have the old provider stored with it, so at that point they will not match, but of course the data can still be decrypted (assuming the key itself hasn't changed and retrievable). If that doesn't answer your question, will you please clarify what you're asking?

2) It could be somewhat more secure if the information about encryption method and key provider were not stored with the data, but it's a tradeoff: There's a much higher chance of not being able to decrypt the data later and the data is not that much more secure. With the new configuration interface that I've introduced, it would theoretically be possible to only store the configuration name with the data; then the encryption method and key provider could be looked up when the data is decrypted. In that case, though, the information is still being stored in the database, so it really only adds a bit of obfuscation. If the database is compromised, the same information is available, unless somehow the intruder only gets access to the table with the encrypted data, but not to the configuration settings, which is unlikely. If you really wanted to take that extra step, you would need to store the configuration settings outside of the database; in a file outside the web root, perhaps, or on another server altogether. It's not an unreasonable idea, but any extra effort would probably be better spent on making sure the key itself is secure.

tobiberlin’s picture

Thank you for your explanations. It seems to me that I was a little bit confused when checking what is stored in database. Now it is clear to me. I am not very familiar with encryption methods and how all this stuff works but still I would prefer a table which stores the encrypted data without any information about encryption method and (internal) encryption key name. The module Private number managed it that way I think. I see that this module (Encrypt) offers different encryption methods and as I see in the settings you define the default method - but you can choose to use another method when using encrypt() . It is quite clear that ii is neccessarry to store information about the method somewhere. And maybe it is not really a security issue - as I mentioned above I am not very familiar with encryption techniques. Just wanted to understand a little bit more what I think was achieved by your explanations.

Thank you!

rlhawk’s picture

Status: Active » Closed (works as designed)

You're welcome. I'm closing this issue, but if you want to make a proposal for saving encrypted text without storing the metadata with it, feel free to create a new issue. And, of course, if you have a patch to submit, even better.