2

I have some database columns which are encrypted. Obviously there is no way to filter these by plaintext value. As the data stored in the db is ~~salted~~ combined with the IV, there is no way to recreate the cypher text.

The value in the database is created like so:

db_value = base64(json([iv, cypher, mac]))

...so without the IV, I can't create db_value. And I can't find the IV without reading db_value.

I could get around this by creating another column to store a hash of the data.

Is this a bad idea? Would keeping the data in multiple formats like this make it less secure?

Improve this question
10
  • 1
    Your question is unclear : you say that some columns are encrypted + salted. Don't you mean they are hashed + salted instead ? If it's the case, what you want is to create another column with an unsalted hash of the same data ? Strange, or I misunderstood something :)
    – niilzon
    Commented Mar 15, 2016 at 13:09
  • 1
    @niilzon I believe he means encrypted columns. There are multiple reasons to keep encrypted blobs of information in databases including PII. His problem now is searching those databases for the encrypted data.
    – RoraΖ
    Commented Mar 15, 2016 at 13:17
  • @RoraZ I undertand that, but I never heard of salting encrypted data, as far as I know one can salt plaintext for hashing to prevent usage of rainbow-tables during cracking. I'm confused, but I don't know everything so I'll just watch this page ;)
    – niilzon
    Commented Mar 15, 2016 at 13:28
  • Sorry if I'm describing it wrong! Basically the encryption isn't deterministic. The cypher and salt are combined into the same field in the database, meaning the only way to get the salt and re-encrypt the plaintext would be to go through each row individually, which defeats the purpose. I know that making a salt as I described would work. I'm just not sure if it is sensible.
    – Mr_Chimp
    Commented Mar 15, 2016 at 13:33
  • You keep using those words... I don't think they mean what you think they mean... ;o) If the encryption wasn't deterministic, you wouldn't ever be able to decrypt anything... Perhaps give us some (pseudo) code for your algorithm instead of badly describing it?
    – deceze
    Commented Mar 15, 2016 at 13:35

1 Answer 1

Reset to default
5

So, you want to be able to quickly test if some data is stored in the encrypted database, without having to decrypt the database.

Now, if you can search this database without decrypting (without the key) then so can an attacker search the database without the key. So, yes in general this is less secure.

Improve this answer
2
  • Thanks. When you put it like that it seems quite obvious. Are there any general ways to mitigate this or otherwise get around the problem?
    – Mr_Chimp
    Commented Mar 15, 2016 at 14:57
  • 1
    If all the data is encrypted with the same key, it is (depending on the encryption scheme) safe to encrypt the search-index with that key as well. Then with the key you can decrypt the search-index, and thus search efficiently, but an attacker can not (needs the key). A not general solution: you could also decide that the search-index does not contain secret material and so not decrypt it. Is that secure? Maybe, define secure ;)
    – Ishtar
    Commented Mar 15, 2016 at 15:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .