Encrypt/decrypt - Ability for multiple keys

[lcallif]

The current encrypt/decrypt allows for one key. I would like the ability to have unlimited keys (possibly number them: 1,2,3,nnnn). Allowing for the ability to specify which key would be used for the encryption/decryption call. This allows for the ability to use a different encryption key based upon table and/or a User.

The goal is not to necessarily to stop a hacker, but to make it as difficult as possible for them to decrypt the data. As multiple companies have stated: It isn't a matter of if a hacker will steal the data, it is a matter of when.

Let's take the following example:
Assume we are storing customer PII in a table called custPII. Assume that the database AND the key were stolen. The data may as well have been stored without any encryption.

Now assume we have the same table.
We have nnnn keys, the encryption key used is one of the nnnn keys available. To make this even more challenging for the hacker, we could use one of the available keys based upon some algorithm specific for that User - maybe based on the birthyear * member year / 2.4 + 32. The key selected for the encryption will not be the same for all entries. This now makes it more difficult for a hacker to decrypt the data in the custPII table. Not impossible, just more difficult.

Also, just because we specified the key for the Customer's data in the custPIII table, doesn't mean that we would use the same key in another table, I wouldn't.

My preference is to NOT replace the Laravel encrypt/decrypt feature. Enhance maybe, not replace.

Any suggestions how I could accomplish this ? Please ?

Or if I am in the wrong place for this question/request ? If so, where should I be entering this ?

Thank you.

[netpok]

You can create multiple instance of the encrypter by passing the encryption key:
new Encrypter('key', 'cipher');

But the question is where does the keys are coming, you're app needs them to access the data? Generally when both the database and your app key is stolen than probably your source code is accessible too, so any key generated from the data is trivially accessible too.

[lcallif]

Thank you!! I wonder if the decrypt in the blade will use the same key. I assume so, but testing will prove this out.

And I agree with your statements.

I just need to make this as difficult as possible in order to protect the data as best as possible. As others have stated: It is not a matter of "if", it is a matter of when hackers will make your life difficult.

So, keeping that in mind, I want to make this more difficult for the hackers to see the data knowing that it this will NOT be 100% successful no matter what we do.

We are doing the following:
1) Db and programs use different username/password (nothing earth shattering).
2) The keys will be stored away from the .env and config files. Most likely the keys will
be kept out of from the database. I have used this encryption process in the past where
we kept the keys in and out of the db.
3) In the past I have encrypted the encryption key just to add one more step of
difficulty. We are currently doing this with all of the Users' files.
- The Zip file's name is randomly generated, the Zip file is password protected and
the key for the password is potentially different for each file.
I am not sure if we will be doing this as I am not convinced that it is worthy
to do with the added execution time. Probably not at this point.

Yeah I know, we may be going overboard with this encryption stuffff, but we reallllly don't want to be in the news for the wrong thing. :-)

Thanks again!!!!!