Home/ Questions/Q 7074195
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T06:01:23+00:00

I’m working on a project that uses pkg_crypto to protect users’ personal information. There

  • 0

I’m working on a project that uses pkg_crypto to protect users’ personal information. There are several thousand rows (which is expected to grow to maybe several tens of thousands), and whenever I use a WHERE or ORDER BY clause in a query, the whole table is decrypted before the results are returned. This takes several seconds for a single query, which is usable for development but will probably not be very good for the release.

Is there a way to create an index that will work on the encrypted columns without compromising security?

The inserts and selects look something like this (with iBatis):

insert:

INSERT INTO "USER_TABLE" 
(
"ID"
,"LOGIN"
,"PASSWORD"
,"NAME"
,"EMAIL"
)
VALUES
(
user_table_seq.nextval, 
#login#
,#password#
,pkg_crypto.encrypt(#name#, 'key')
,pkg_crypto.encrypt(#email#, 'key') 
)

select:

SELECT 
"ID"
,"LOGIN"
,"PASSWORD"
,pkg_crypto.decrypt("NAME", 'key') NAME
,pkg_crypto.decrypt("EMAIL", 'key')  EMAIL
FROM "USER_TABLE"
WHERE pkg_crypto.decrypt("NAME", 'key') LIKE #name# || '%'
AND pkg_crypto.decrypt("EMAIL", 'key') LIKE '%' || #email#

I’ll preemptively put out there that the password is hashed by the servlet before being passed to the db.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Substantially, the answer is No.

    When each value is encrypted, it has a random IV (initialization vector) chosen to go with it. And this means that you cannot predict what is going into the index. If you re-encrypt the value (even with the same key), you will get a different result. Therefore, you cannot meaningfully use an index on the encrypted value because you cannot reproduce the encryption for the value you’re searching for. The index would, in any case, only be useful for equality searches. The data would be in a random sequence.

    You might do better with a hash value stored (as well as the encrypted value). If you hash the names with a known algorithm, then you can reproduce the hash value on demand and find the rows that match. But simply knowing the hash won’t allow you (or an intruder) to determine the value that was hashed except through pre-computed ‘rainbow tables’.

    So, you cannot meaningfully index encrypted columns – not even for uniqueness (since the same value would be encrypted different ways by virtue of the random IV).

    • 0