108 reputation
3
bio website danrowlands.co.uk
location United Kingdom
age 32
visits member for 2 years
seen Jul 2 at 8:07

Jul
22
awarded  Student
Jul
18
awarded  Scholar
Jul
18
accepted Least insecure way to encrypt a field in the database so that it can still be included in queries
Jul
18
comment Least insecure way to encrypt a field in the database so that it can still be included in queries
This is the solution I'm going to use. Thanks for your help.
Jul
17
awarded  Commentator
Jul
17
comment Least insecure way to encrypt a field in the database so that it can still be included in queries
@David It's possible for SenderID to be traced back to a real person. So if you imagine that it's a person's name (it's not but just as an example) and that name is present in a table called Bankrupcy or PreviousArrests etc. You may not be able to read all the content but the very fact they exist in the table leaks information.
Jul
17
comment Least insecure way to encrypt a field in the database so that it can still be included in queries
This does look like a good solution, as you say it was designed for this purpose and is obviously better than simple hashing. Could you provide any information on why the HMAC approach is more secure than a Fixed IV encryption approach?
Jul
16
comment Least insecure way to encrypt a field in the database so that it can still be included in queries
Thanks Stephane this is an interesting, I briefly considered HMAC but didn't put much time into researching the option. I'll take another look.
Jul
16
comment Least insecure way to encrypt a field in the database so that it can still be included in queries
If I understand salts correctly, they exist to prevent pre-computed lists of hashes being used to brute force a hashed value. However considering we only have a 10 digit integer and the salt would be essentially stored with the hash, would it make any real difference in how long it would take to run through all the combinations?
Jul
16
comment Least insecure way to encrypt a field in the database so that it can still be included in queries
Unfortunately in my real world problem the SenderID equivalent is a 10 digit integer.
Jul
16
comment Least insecure way to encrypt a field in the database so that it can still be included in queries
In this case SenderID just identifies a person. It's entirely separate from username/password authentication.
Jul
16
comment Least insecure way to encrypt a field in the database so that it can still be included in queries
My concern with this method, is that the SenderID follows a fixed format, so I don't imagine it would take very long to brute force the values even with a "slow" hash.
Jul
16
comment Least insecure way to encrypt a field in the database so that it can still be included in queries
@Stephane, regarding the fixed IV, I assumed that the encryption would be more secure than hashing because there is a secret key component. An attacker with the data base could generate hashes of all possible SenderIDs (as it's a fixed format). Whereas even if they had the data dump they wouldn't know the encryption key.
Jul
16
comment Least insecure way to encrypt a field in the database so that it can still be included in queries
@Stephane, yes sorry for the confusion. I mean the field needs to be matchable. No sorting, ordering or partial searches required. And yes, we'll have the SenderID in plaintext to execute the search.
Jul
16
comment Least insecure way to encrypt a field in the database so that it can still be included in queries
If the SenderID was plaintext you would know that a message had been sent by a particular user even if you couldn't read the content. For our threat model this is unacceptable data leakage.
Jul
16
asked Least insecure way to encrypt a field in the database so that it can still be included in queries