Decrypt My Files

encryption
nc13

#1

I decrypted (and disabled encryption on) my install (using occ encryption:decrypt-all) and then downloaded my files, but the files were still encrypted. I have the keys that the server used and the recovery password.

Am I able to decrypt and recover my files?

Update: I have the database dump.


Signature check during encryption / decryption
Decrypt Files with Recovery Keys
#2

You also need the database because the files were signed with database information. In theory, you should be able to recover files without the signature check but this would need a modification of the code.

Regarding decryption, there are already a couple of bug reports:




#3

I found a dump of my database. I realized that I don’t have my user keys, but I do have the account password. What do you suggest I do next?


Decrypt Recovered Files
#4

You need the user keys and the user password (or master key), with the database you should be able to restore the setup and get the data:
https://docs.nextcloud.com/server/13/admin_manual/maintenance/restore.html


#5

So to confirm, I can recover files without the user’s personal keys (anything in data/[my username]/files_encryption) but with the master keys in data/files_encryption/OC_DEFAULT_MODULE?

Also, what are recovery keys used for? I have the master recovery keys and I’m wondering if I could just use those to decrypt anything.


So far, I’ve:

  1. Set up a new Nextcloud install.
  2. Replaced the database with the dump I recovered.
  3. Update the config file with the one from my old install. Replaced the instanceid, passwordsalt, and secret fields.
  4. Import the keys from my old install to data/files_encryption/OC_DEFAULT_MODULE.
  5. Upload an encrypted text file and run the command to scan for new files.
  6. Try to open the file, it gives the error “Can not decrypt this file, probably this is a shared file. Please ask the file owner to reshare the file with you.” I assume that this is because there is no corresponding key in data/[my username]/files_encryption/keys/files.

I then ran the command occ encryption:encrypt-all in hopes that it would generate a key for the file, but it just said that the file was already encrypted.


#6

Anyone got any ideas?


#7

You have a key for each user, and then a key for each file. You’ll probably need the key for each file; not sure about the user key if you need it on top of the master key. @bjoern could be answer it for sure…

Unfortunately documentation and tools are very poor when you can’t restore a complete system with server-side encryption. Considering all the open topics, it’s a good idea to test a full backup and recovery procedure…


#8

Hi,

you have to distinguish between the master key and the recovery key. In general Nextcloud provides to possible setups:

  1. Every user has it’s own private/public key and the Admin can additionally offer a recovery key which each user need to accept (opt-in). In order to decrypt the user files with occ you need either the users password and in this case the users private key + the file keys + the database to check the signature or the recovery key password (if the user enabled the recovery key). In case of the recovery key you need the private recovery key, the password of the recovery key, the file keys and the database. This was the default setup until Nextcloud 13, you could enable the master key with occ encryption:enable-master-key, in this case setup 2 is used.

  2. A master key is used. This is the default if encryption was enabled for the first time with Nextcloud 13 or later or if it was enabled by the admin with the occ command occ encryption:enable-master-key. In this case there is only one key used for all files of all users, the private key is encrypted with the instance password. In order to decrypt all files with the occ command you only need the private master key, the file key and the database.

For the database, it is important that the database is from the exact same time as the files in your data folder. Every time a encrypted file is updated we increase the “file version” in the database. Only if the “file version” stored in the database matches the version of the real file it is possible to decrypt it again. Otherwise you would have to disable the signature check.

If you don’t have the necessary keys (either from setup 1 or setup 2, depending what is your setup) and a system where your files and database are in sync, decrypting the files is not possible. Don’t run “encrypt-all” if your files are already encrypted. Yes, it will generate missing encryption keys, but this keys will be useless with the already encrypted files as they were encrypted with a different key.


Can I decrypt files with cli?
#9

Hey, its possible to decrypt nextcloud files, if i only have nextcloud data ?
cache
files
files_encryption


#10

Same situation as @janar here: I’ve got all files from the NC data directory, where some newer files are encrypted (setup 1 as described by @bjoern), but the database backup is out of sync with the file system. Is there any way to decrypt the files - maybe manually without occ?


#11

In theory yes. You can somehow disable the signing process or disable the verification of it. I tried it a bit but didn’t get it working (I’m not a programmer, so don’t be discouraged):


#12

Yes, you could disable the signature check by editing the code.But this is really not recommended. Only see this a action of last resort if there is no other way to decrypt your files again!

If you edit this file https://github.com/nextcloud/server/blob/master/apps/encryption/lib/Crypto/Crypt.php#L481 and add between L480 and L481 “return true;” This way the signature check will always return true, but as said, that’s not a solution but only something you can do if nothing else helps.


Bad Signature: Decrypting files
#13

I reopend the topic for disabling the signature check here:


#14

The reason why turning off the signature check isn’t enough, is that the server reports a different filesize to the client and breaks off the download too early. The client therefore thinks that the connection was lost and reports an error. But the file is already downloaded successfully (f.e. in Chrome you just have to remove .crdownload at the end of the downloaded file). I have written a small Python 3 script that can download the files via WebDav. It is a dirty hack, but at least I can recover my files.

You can find the script including an explanation in my gitea repository:
https://gitea.hibiki.eu/suntorytimed/nc-downloader


#15

After checking the downloads I discovered that while the JPEGs open without any problem my RAW files didn’t. Looking closer at the JPEGs I could see that in the last pixel line there were some blocks missing. So the download wasn’t finished. Following up on the error message that gets displayed in Nextcloud in the hasSignature() call of splitMetaData() I discovered that the encrypted data field was empty and therefore there can’t be a signature in the file. To bypass this I have added following if clause into the function symmetricDecryptFileContent() in apps/encryption/lib/Crypto/Crypt.php:

            if ($keyFileContents == '') {
                    return '';
            }

I have put this code as the first command in the symmetricDecryptFileContent(). Together with disabling the signature check (putting return true; in the checkSignature() function in the same file):

    private function checkSignature($data, $passPhrase, $expectedSignature) {
            $signature = $this->createSignature($data, $passPhrase);
            if (!hash_equals($expectedSignature, $signature)) {
                    return true;
                    throw new GenericEncryptionException('Bad Signature', $this->l->t('Bad Signature'));
            }
    }

I can now see the previews in the web interface and download all files decrypted and even download the folders as zip-files. My script is not necessary anymore :slight_smile:


#16

@suntorytimed: Would you accept to take your solution as an answer to this question? For problems, we could refer to your repository and there is still an issue on the bug tracker in case there should be an official tool one day.


#17

@tflidd I assume that my second post is a solution for this problem. At least as long as the user does have a Nextcloud instance with the database, files and keys in place. As long as the decryption only fails because of the wrong signature this answer would help recover the encrypted files.

If the user doesn’t have a database dump, the keys or an old instance that was used with the encryption the user can’t recover the files using this method.

The script is not really necessary anymore as the web interface can handle the download now as well.

I have submitted the empty string check as a fix to the upstream project. Even though this might not happen so often it is still better than having an exception (but I let the maintainers decide this). If this is merged the user only has to deactivate the checkSignature() by adding a return true;. I would still prefer an option call in occ though.

You can find the request here: https://github.com/nextcloud/server/pull/10778