You are not logged in.

#1 2024-05-19 16:20:10

zw
Member
Registered: 2022-05-31
Posts: 18

Feedback on plan for encrypting files before putting them in Nextcloud

I use Syncthing to sync some plain-text notes between my phone and my desktop, where they are in the ~/notes/ directory. I want to set up a daily cron job that saves an encrypted copy of these notes to my Nextcloud, which is hosted by a cloud provider.

The main purpose of the cron job is to have a daily backup of the notes so I can find old versions in case I accidentally delete something. But I want to encrypt the notes in Nextcloud to mitigate the risks in case of a vulnerability in Nextcloud or data breach at the cloud provider. For reasons irrelevant to this discussion, I don't want to use Nextcloud's built-in E2E encryption plug in.

My plan is to do this in the cron job:

1. Generate a strong password with pwgen -s -1 128 > ~/notes_keys/.$(date -I)_encryption_key.
2. Compress and encrypt the notes: key=$(< ~/notes_keys/.$(date -I)_encryption_key) followed by 7z a -p$key ~/nextcloud/notes.7z ~/notes/* (I guess I should store the date in between to prevent a race condition).

Now my Nextcloud has the encrypted notes, and my hard drive has the (plaintext) encryption key. So, if I want to restore a note from, say, 2 days ago, I can open that version of the notes.7z archive in Nextcloud and decrypt it using my (local) copy of the encryption key.

My question is, am I exposing myself to any new risks by adopting this backup strategy? I am comfortable with keeping the notes in plaintext on my computer and phone because these are already using FDE (which is good enough for me), so I don't think I'm creating any new risks by keeping the encryption key in plaintext, too, right?

Second question: How would the risk picture change if I save the keys into the notes directory, too? (thereby syncing the keys to my phone, and to Nextcloud in encrypted form).

To reiterate, the main risks I am concerned about are:

1. Data loss due to user error, accidental rm -rf *, etc (covered by daily backup)
2. Leak of personal info due to someone stealing my phone (covered, hopefully, by encrypting the storage).
3. Leak of personal info due to vulnerability in Nextcloud or data breach at hosting provider.

Offline

#2 2024-05-22 15:33:01

256
Member
Registered: 2023-12-17
Posts: 14

Re: Feedback on plan for encrypting files before putting them in Nextcloud

Rather than any new risks, I'm not sure your plan solves the problem of data loss in the first place.

You can recover from deleting most files, but what if you lose the keys? Also, why do you have more than 1 key? What advantage is there to having more than one?

If you lose them, can you re-type them from memory?

Also, what if there's an error reading the password file, and $key is a null string? I assume 7z would throw an error message, rather than using a null string as a key, but it's worth testing to be sure.


"Don't comment bad code - rewrite it." - The Elements of Programming Style (1978), Brian W. Kernighan & P. J. Plauger, p. 144.

Offline

#3 2024-05-22 16:03:14

cmm11
Member
Registered: 2018-02-18
Posts: 50

Re: Feedback on plan for encrypting files before putting them in Nextcloud

I would use borgbackup to handle the encryption and backup of the files then use rclone to sync the borg repo to your nextcloud (borgbackup & rclone are both in the Arch repos)
Borg can use a repo key that requires a passphrase (which you could store in your favorite password manager) , so no plaintext keys laying around a system.
It will easily allow you to view previous backups and since the backup is going to happen daily, borg being able to do de-duplication will mean the actual size of data used on your nextcloud will be way smaller than the way you posted.
https://borgbackup.readthedocs.io/en/stable/
https://rclone.org/


$20 Free Credit Hetzner - https://hetzner.cloud/?ref=fuVilhv403fA

Offline

Board footer

Powered by FluxBB