The answer to your question is technically "yes", but there are some noteworthy
implications to consider specific to the use case of backups.
There are two main server side encryption schemes in Nextcloud. Recent versions
of Nextcloud use a "master key" by default, which can decrypt everything.
There is also an alternate implementation of encryption based on per-user keys,
which applies to older set ups, or people who disabled master key encryption manually.
If you see something like this, it's using the per-user (old) style:
Here is a description from one of the authors of the Nextcloud Default
Encryption Module plugin:
In general Nextcloud provides to possible setups:
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.
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 per-user method of encryption (old style), the keys are protected
by the Nextcloud user's login password:
Nextcloud’s server-side encryption generates a strong encryption key, which
is unlocked by user’s passwords. Your users don’t need to track an extra
password, but simply log in as they normally do. It encrypts only the contents
of files, and not filenames and directory structures.
(See Encryption configuration — Nextcloud latest Administration Manual latest documentation).
For the master key implementation (which is the current default and most
likely what you'll use), the absolute minimum needed to have a chance at
decrypting the data is 1) the master key pair, and 2) a secret from
config.php. To follow the official process (i.e. to ensure success), you
also want a dump of the database from after the files were encrypted. You can
attempt to break the encryption without the database by disabling file
signature checks, but your mileage will vary.
So yes, you can put the keys in plain text along with the encrypted backup in
something like Dropbox with relative safety. Without the secret from config.php,
it's unlikely that an attacker would be able to decrypt the data. This also
means that you won't be able to. If you have the keys and the config.php
secret, but the database is encrypted, you're stuck with attempting to break the
encryption by disabling signature checks. For a smooth recovery you'll want the
master key, config.php file, and an up-to-date database snapshot, all saved
securely somewhere else.
At this point, I think the convenience factor of keeping the keys with the
backup is negated. Another annoyance would be the restore process. You'd still
be spinning up a new Nextcloud instance to decrypt the data. The decrypted data
would then be a full backup of your Nextcloud instance, which would itself need
to be imported/restored to a Nextcloud instance.
Using another approach, like this one, might make your life easier in the event
that you do need to restore from a backup after a total loss:
https://kevq.uk/how-to-backup-nextcloud/
There are plenty of similar examples for backups like this posted online. The
key points are:
- A full backup is taken, a single snapshot that can be used to easily rebuild
following the official documentation
- The backup is compressed into a single file which is easier to transfer
and encrypt
- The encryption concern is decoupled from Nextcloud itself. You can choose any
method that suits your needs, using standard tools like GPG
- Encrypted backups are stored at some remote destination which supports API
interactions via CLI, such as S3 or B2
- The whole process is just a script - automate it with cron, and run it
manually whenever you want
- Adding another backup source is low-friction - just write another step in the
script to also copy the file somewhere else
- To restore, all you need to do is fetch the latest backup, decrypt it (with
standard tools that you chose), copy it to the right place on a new instance,
and follow the official guides (even easier for snap installs)
Hope this helps! Encryption in Nextcloud is deceptively easy to set up, but it
definitely comes with risks and trade-offs. There's no shortage of forum posts
and GitHub issues with tales of lost data using Nextcloud encryption.
I've been using Nextcloud as the main driver of an "I don't need Google" set up
for a couple of years now. It's been shockingly low-maintenance, very reliable,
and rewarding to customize. I hope you give it a try!
