Forum Stats

  • 3,770,460 Users
  • 2,253,117 Discussions
  • 7,875,465 Comments

Discussions

BDB JE Encryption Question

3236964
3236964 Member Posts: 8
edited Dec 24, 2016 11:48PM in Berkeley DB Java Edition

Hi,

I need to encrypt certain privacy fields such as name, address, birthdate etc in my database.  I am using the DPL api.

Currently, I am pursuing the strategy of encrypting these fields with symmetric  AES/CBC/PKCS7Padding 256bit  encryption.  The weakness with this strategy is that for fields that I am encrypting,  those fields can not be used as SecondaryKey's because the encryption makes random outcomes as it should.  So if I had a SecondaryKey in the Employee class called "lastName", which as was encrypted, a SecondaryIndex search by last name would not be reliable.

I believe my only choice is to remove the SecondaryKey index for that field and do a slower query by fetching the Employee's into memory and then filtering them with java for attain intended result.

Am I missing something that I don't understand with the JE api that would make encryption easier?  Is there some hook that I can plug into to write the entities data byte[]. The indexes themselves do not need to be encrypted, just the data bytes.

It's too late for me to switch back to the Base API.  I also do not want to use the core edition of BDB because the JE is nicer to work with.

Thanks for any guidance you may offer,

Scott

Message was edited by: 3236964 Oh I see that the PrimaryIndex can be created directly with a constructor that takes an EntityBinding.  This may be the answer?

Best Answer

  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    edited Dec 24, 2016 8:42PM Accepted Answer

    Hi,

    I don't think you're missing anything in JE. But I don't understand why you want the lastName field encrypted in the data, but not as a secondary key. Since both are written to disk, why don't you need the key to be encrypted?

    One option is to encrypt the key when you do the query, and then de-crypt it and filter records out of queries that don't actually match (because two different lastNames happen to have the same encrypted value).

    --mark

    PS. We are all out of the office next week, so I may not reply again until after the New Year.

Answers

  • Greybird-Oracle
    Greybird-Oracle Member Posts: 2,690
    edited Dec 24, 2016 8:42PM Accepted Answer

    Hi,

    I don't think you're missing anything in JE. But I don't understand why you want the lastName field encrypted in the data, but not as a secondary key. Since both are written to disk, why don't you need the key to be encrypted?

    One option is to encrypt the key when you do the query, and then de-crypt it and filter records out of queries that don't actually match (because two different lastNames happen to have the same encrypted value).

    --mark

    PS. We are all out of the office next week, so I may not reply again until after the New Year.

  • 3236964
    3236964 Member Posts: 8
    edited Dec 24, 2016 11:48PM

    thanks for the reply Mark

    Yes, you're right, it doesn't make too much sense to leave the key value unencrypted.  I think at this point I may just encrypt the field and not make it a SecondaryIndex.  I don't have too many of these fields, and I can do the encrypt/decrypt from my data layer without too much trouble.

    Enjoy your week off

This discussion has been closed.