Greetings,
* Bruce Momjian (bruce@momjian.us) wrote:
> On Thu, Oct 10, 2019 at 10:40:37AM -0400, Stephen Frost wrote:
> > > Some people ask for indexable encrypted columns, but I tend to explain to
> > > them how impractical and inefficient that is. You can support hash indexes
> > > if you don't salt the encrypted data, but that greatly weakens the
> > > encryption by allowing attackers to use dictionary attacks and other brute
> > > force techniques efficiently. And you can't support b-tree > and < without
> > > very complex encryption schemes (
> > > https://en.wikipedia.org/wiki/Homomorphic_encryption).
> >
> > I'm not sure why you wouldn't salt the hash..? That's pretty important,
> > imv, and, of course, you have to store the salt but that shouldn't be
> > that big of a deal, I wouldn't think. Agreed that you can't support
> > b-tree (even with complex encryption schemes..., I've read some papers
> > about how just </> is enough to be able to glean a good bit of info
> > from, not super relevant to the overall discussion here so I won't go
> > hunt them down right now, but if there's interest, I can try to do so).
>
> Yes. you can add salt to the value you store in the hash index, but when
> you are looking for a matching value, how do you know what salt to use
> to find it in the index?
Yeah, if the only value you have to look up with is the unencrypted
sensitive information itself then you'd have to have the data hashed
without a salt.
If the application had some way of providing a salt and then sending it
to the database as part of the query, then you could (we used to do
exactly this with md5...). This probably gets to be pretty use-case
specific, but it seems like if we had a data type for "hashed value,
optionally including a salt" which could then be used with a hash index,
it'd be pretty helpful for users.
Thanks,
Stephen
