"Guru" question about encryption

[Kent Multer]

Hi folks,

One of my clients is having a problem with an older module of mine, which isn't compatible with the encryption features in newer versions of MM. The module stored some encrypted data in its own DB table, not in OrderPayments. The client recently ran the Encryption Wizard to update their store's key. Now they can no longer decrypt the data saved by the module, and the old key was deleted when they ran the wizard. Bummer ...

To fix this, I think I need to start by returning the store to the old key. We remember the old passphrase; it hasn't been that long. The Wizard says that "A different passphrase should be used each time you generate an encryption key," but I don't think it actually prevents you from re-using an old passphrase. However, it occurred to me that the key-generation process might use a time stamp or other unique data, so that using the same passphrase twice might produce two different keys. Can someone please confirm whether or not this will work? Does a passphrase always produce the same key?

If I get the old key restored, I can write code that will decrypt the data using the old key, and save it in the OrderPayments table. Then I can update the module to use OrderPayments instead of its private table. Once that's done, they can run the Wizard whenever they want, and the module's data will get re-encrypted along with everything else. The critical part is restoring the old key; hope someone can give me some good news about that?

Thanks --

[ILoveHostasaurus]

The same pass phrase will not produce the same encryption key. I'd recommend having a copy of the site dated before the change restored to a dev environment, then you can extract the data and move it over to the live store.

[Kent Multer]

Hi David, that looks promising. I seem to recall that you folks charge some small fee to set up a dev store; is that correct? Can we just contact Support and ask them to set this up, using an old backup copy of the store?

Or how about this: instead of restoring the whole store, if I get a backup copy of the s01_Encryption table, I could manually copy the old key into the live store's table, and then write my recovery program to run in the live store. Would that work?

Thanks for your help --

[ILoveHostasaurus]

We've written software to automate most of development site creation now, so the fee for those was eliminated I believe a week ago. Depending on the scenario, there may be a small fee to restore from backup.

Yes on your other question, it would be trivial to create a new 'restore' database and restore specific data to it if that's all you need, then you could grab it via phpmyadmin or have your script talk to that db specifically.

[Kent Multer]

Hi David, that looks promising. Just to be clear, let's see if I've got this right. The steps to follow are:

1. Get the old s01_Encryption table from a backup, by restoring the backup into a DB with a different name.

2. Use phpMyAdmin to manually read the old encryption key from the table, and add it to the s01_Encryption table in the live store.

3. Write my own code to decrypt the old data using the restored key, and then re-encrypt it using the store's current key.

4. Save the decrypted data in the s01_OrderPayments table, using fields such as pay_id and refnum to distinguish these records from normal payment records.

5. Modify my module to work with data in OrderPayments, instead of using its old private table.

6. Once this is done, the store can update their encryption key any time, and the module will stay in synch with the rest of the store.

Is that correct?

Thanks --

[ILoveHostasaurus]

I don't think that would work. When you use the encryption wizard, you're given two choices; you can either reencrypt existing orders using your new key, or delete payment data from the past orders and only use the new key for orders going forward. So restoring the old key would not provide you with a key that is usable for anything currently in the store orders table, if anything is there at all for those old orders. It sounds like in this case the only option would be a restore of the store to a dev site to bring back both the old orders and the old encryption key, then migrate data between.

[Kent Multer]

Sorry if I wasn't clear. My intention is to use the old key only for a one-time process, so I can decrypt the data and immediately re-encrypt it using the store's current key, and then store it in the OrderPayments table instead of a custom table. I guess I forgot step 7, which will be to delete the old key from the live store, since it won't be needed any more.

Basically, I'm hoping to do all the work within a single store, since that will be easier than decrypting in one store and transferring the data to another. There are a few thousand encrypted records to convert.

Thanks --

[ILoveHostasaurus]

Oh, was the prior key used for your custom table? That would work if you have a method to use that specific key and know its pass phrase. As long as you don't care about any data that had previously been in the orders tables, encrypted with the old key, you would be okay. If you do care about data in the store orders tables that had previously been encrypted by that key, it would not be usable since the data would have been reencrypted with the new key, or discarded, based on what the store owner chose.

[Kent Multer]

Right, the old key is only needed to decrypt data in the custom table. After that, I will transfer the data to OrderPayments, re-encrypting it with the store's current key. I think we've answered all the questions. Thanks again for your help! --