it would be great if it was possible to decrypt files when encryption was enabled with just the files and the corresponding keys as well as the (recovery) password. Currently, it is very difficult to restore files when encryption was enabled on the server and one has to restore some of them from a backup. The only viable way as it is now is to restore the whole system on a separate server/vm and then retrieve the files. Simply putting the files/keys in place and run occ to decrypt them won’t do anything.
This should be possible with either the occ tool or some other recovery tool.
Not exactly sure why sharing the admin_manual was supposed to useful. There is no information for retrieving a single file from a single user. Which is what this feature request is asking to support in the future.
ianathompson is right. The occ tool only allows you to decrypt files if the whole Owncloud installation is up and running. And since 8.2 changed the way encryption is done fundamentally there is basically no 3rd-party script available that works. Anyway, this should be available in core and not some 3rd-party script that does not get maintenance as needed.
If one needs to decrypt a few files then the only option is to restore the whole owncloud instance to decrypt them.
I actually try to implement such a process, although this will not be developed as an “inline nextcloud app” (at least not for now…). My starting point is the daily backuped files (from the “data” directory).
My goal is to “get hold of the encrypted file and the administrator’s recovery key. then use the (known) recovery password and have the file decrypted”. Then the decrypted file will be “handed over” to the original user again.
Most of that process is working already for my environment, next step would be the actual decryption.
Currently I am getting an OPENSSL error, when trying to decrypt the “recoverykey” file:
Fatal error: Uncaught Exception: Missing Signature in /…/crypt.php:237
Where could I get some “deep-diving” knowledge of the decryption process?
I removed all “namespace” definitions at the top of the library, and replaced all $this-> … method calls by direct function calls. No other changes were nessessary so far.
calling $recoveryKeyDecrypted = decryptPrivateKey($recoveryKeyEncrypted, $recoveryPassword); [codeline 392 in github]
results in the mentioned error message in the method hasSignature [codeline 557 in github]
So it looks like my recoveryKey is expected to have a signature, but actually this is not found in the key…
The signature is created with a key which is a combination of the file-key + file-version + block-number. The version is stored in the file cache table and get’s increased every time the file is updated. So if you just have a backup of the files there is no way to verify the signature again. But it should be possible to ignore the signature and just decrypt the content as it is. Of course this means that you will not notice if someone changed the file on your backup or on your server right before you created the backup.
I do actually backup the file-cache database table as well (actually twice, once BEFORE the files are backuped, and once after, so I can verify I have the relevant datarecord for that file - except for the “very” remote chance, that the file gets edited TWICE during the whole backup process).
So let me have a look at the filecache table and see if I can figure out what exactly you mean…
will be back soon with more questions I belief…
OK, lets assume I want to restore the file “Test-fuer-Ruecksicherung.txt” from my “/privat/” folder… In the filecache-table I have this record for it. So what does this record tell me (and where is this “version” incremented)?
Thanks tflidd, I looked at that script and it seems that arno01 is decoding the key files first from BASE64. I tried this but the result is not nearly useable. So I am afraid I really need some help here…
The “keyfile” for that given file (test file only) looks like this:
Offset (h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
Offset (d) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15