MySQL CBC Encryption and Storing Initialization Vector

0
votes

I'm working on a HIPAA project and it has come to my attention that I need to encrypt all column level data that does or may contain private health information. That said I'm looking to use the AES_ENCRYPT and AES_DECRYPT with MySQL in block_encryption_mode=aes-256-cbc. It looks like I need to have an IV (initialization vector) uniquely for each row in the table. I will need this same IV to both encrypt and decrypt. Should I just store it in a column in the database or something else?

Also for the column type is it better to use varbinary/blob or HEX the encrypted results and put it into a varchar/text?

Any other suggestions are most welcome to keep the data as secure as possible.

1
mysqlencryptionaes
if you're storing the key with the encrypted data, you've accomplished nothing. it's the equivalent of a bank vault with the lock's combination written beside the lock. encryption isn't just something you can check off on a marketing checklist. there's a whole pile of OTHER stuff that has to be deal with, to the point that the actual mechanics of enc-/de-crypting and storage of that cyphertext is the least of your problems. - Marc B
I would never store the key with the data...that's just silly. CBC takes a key (to be kept in the web app never in the DB) and an IV. The IV should be random and different by record. - Six of Eighteen
@MarcB the IV (Initialization Vector) does not need to be secret and usually isn't. The IV is not the encryption key. - zaph
Was thinking to keep the key outside of the application and encrypted in a file tucked away some place not obvious with a common extension - Six of Eighteen

1 Answers

0
votes

Store is iv in a column, it does not need to be secret.

I would use a varbinary/blob instead of hex encoding the data.

Note: Base64 is a better option that hex, there is less storage overhead.

Addressing @Marc somewhat: How will the encryption key be protected? How good is the server protection and admin access.