I have come across files in the documents folder that were encrypted by the different keys. (My mistake) Is there a way to decrypt those files?
@juggernautsei ,
How many documents are there and do you have the old keys?
(my thoughts on this would be change the 3 digits at the front of file data from whatever they to something like 00x (actually needs to be an int, so would do 100) or something like that, which would identify it as a file that uses a custom keyset in the keys table; if had this mechanism, then would change the 3 digits and put the custom keyset in the keys table and then should have persistent way to read those documents)
Unfortunately, I don’t have the old keys. The previous set of keys that I did backup does not unlock the files. They are invisible to in the interface. They can be seen in the command line.
I am not sure how many documents it will turn out to be. I know of several right now. I am sure there will be more that we have lost access to that has not been discovered yet.
hi @juggernautsei , I think the old set of keys to unlock the files would be in a database backup unless I’m misunderstanding.
Stephen’s right the keys needed reside in the database
We no longer have access to the original set of keys from the v6 server where the files were encrypted. That server has been decommissioned over a year ago. There are no copies or backups of that server as its use was discontinued in 2022. Now what do we do?
The files will remain encrypted without the keys. And modern encryption can’t be broken. The sixa and sixb keys stored in the keys sql table is what you will need from the prior server database to open those documents.
Thanks @brady.miller. I wanted to make sure I was not missing anything. When I am doing upgrades, I always tell clients to go and check the system but most never check documents. Since I have learned how to do in place upgrades of PHP. I should no longer have the issue of transferring files between servers. But it will happen when clients want to change between AWS and AZURE. Then the possibility arises to loose access to encrypted documents.
You might peek at the “openemr-env-migrator” in the devops repo – I haven’t actually tested this one myself, so no promises there – and I’ve got “ingestion.sh” in the lightsail directory, which tries to answer a lot of the questions of taking a regular old OpenEMR backup export, the tarball, and slurping it into a fresh container somewhere else.
I know my script should work with encrypted documents just fine (although I didn’t test it) because it does slurp up the database along with the documents when it loads everything in.
I think the only way for this to happen would be to remove those keys from the keys table. As long as don’t do that, then should avoid this issue (@juggernautsei , let us know if there was something else that happened to cause this).
Yeah, I meant for migrations in general, not that they’d rescue this situation after the keys were lost.
The point of this thread is to make sure there is no way around lost keys to warn others.
Here is the original thread
This is where the key issue happened during a migration from v5 server to v7 server. The purpose for building the new server was because at the time there was two things that needed upgrading. The OS and PHP. I had tried in place upgrading of the OS but that brakes the LAMP stack. And I had not found a way to fix it. Now, I have finally learned all the steps it takes to do an OS upgrade of Ubuntu and fix the Lamp stack after the upgrade. I will no longer have to move the program from one server to another. This way I should be able to keep the key set intact.
You mention in the final post that you were grabbing a different multi-site database and when you grabbed the right one it had the keys correct for decryption if I’m understanding you correctly. Did something change where you ended up having to delete the database keys in the keys table at the end?
You’re saying you don’t have any database backups that would have had those original keys? Unfortunately, if that’s the case then the data is unrecoverable (that or quantum computing / NSA backdoor would be the only other recourse I could think of).
Looks like I grabbed the wrong post. But similar situation. I generally keep the last active site for 6 months before destroying the site. But now I don’t have to do that since I have learned how to in place upgrades of both server OS and LAMP. I was looking for a quantum computer wait list to see if I can book some time to crack the files.
Since symmetric key encryption with AES-256 don’t even think waiting for a quantum computer will help here 
I learned something new today. Didn’t think AES-256 was good enough for quantum computing but apparently we’re a long ways off to breaking it per this article:
I went ahead and took my name off the wait list. Good news, the files are not lost.
2 Likes
This is relevant to my interests, as I have just started digging into how the V6/V7 encryption works in relation to doing upgrades on large established sites from V4/V5 , to Version 7. I think it’s pretty important for people to understand, even if they don’t grok the encryption itself, they must be fully aware of how critical those keys are. Not only will your environment not run, you’ll lose data without those keys, unless you still have and are capable of reverting to a backup done prior to the encryption going into effect. It’s always a double edged sword that can swing around & cut you back when used improperly. Glad to hear Sherwin got his files back !
2 Likes
@Penguin8R I never lost the files. I still don’t have access to the files. Your comment is why I like to do threads like this. I may expose my failures but it may inform someone else before they get to this point where I am at. I am glad you found this thread useful.