Encryption with SFTP backend is done before or after sending the data?

Restic can use the SFTP backend. I know SFTP provides encryption in transit. However, that encryption is weak because it’s asymmetric encryption, meant to hold up a decade or so. There could also be issues with the SSH key leakage.

Does restic encrypt data prior to sending the data to the SSH tunnel?

It seems Borgbackup encrypts before sending over the SSH. But I am new to both tools.

Also, is there any benefit with SFTP compared to rsync-ing a restic repo over ssh? (other than not having to keep a local copy).

Thank you!

Restic completely encrypts the data before sending it over any of the backends it supports.

Rsyncing a repository is more like copying a repository than backing up to a repository - different things. If you want to copy snapshots between two repositories, you can use the restic copy command. I fail to understand your question/use case though if you want the backup repository to be stored offsite, just back up to it directly instead of rsyncing or similar it?

If restic encryts the data before the data leaves the client’s device (restic running on the client’s machine performs AEAD, not the restic running on the server), then it’s safe and rsync is not required. Otherwise, the data must be encrypted client side (using restic etc) and then rsynced.

I want the data protected with AES-256, concerned with the men-in-the-middle who might save the traffic for future decryption (RSA may not hold up for too long).

I prefer Restic due to a slight concern over Borg’s encryption.

Related question, does restic’s repository password ever leave the client’s device, in any of the restic operations (backup, mount, prune, etc) with respect to a remote server?

For example, when a client does:

restic -r sftp:user:data:~/rep backup ~/

restic -r sftp:user:data:~/rep mount /mnt/

or a similar operation, is client’s repository password sent (in the ssh tunnel) to the server?

Some programs perform some of the operations on the server side to speed up the process, requiring sending credentials to the server.

It totally does, no need to worry about that :slight_smile:

Good thinking ahead. If you use e.g. rest-server, Minio or some other backend that wraps the transport of data in another layer of encryption (with PFS and what not) you’ll have a bit more protection in the long run. But as you say, what we use today will of course be broken at some point, it’s a game of time :slight_smile:

Not at all, the key never leaves the client where restic is running (at least not due to restic’s actions - if you or some wrapper software you use puts the key somewhere else, that’s not something restic can stop). Restic is a client-side only binary and does not have a server component. Whichever backend it works with/over/against, it’s just a storage of files for restic.

1 Like

Thank you, got it.

Then it’s end-to-end encrypted, regardless of how it interacts with its backends (be it sftp, rclone or etc).

The SSH prompt confused me for a moment that the passphrase that I am pasting is being processed on the server side.

As you know, people increasingly back up data on each other computers (called “cloud” or whatever); so it’s important that restic treats a back up server/storage as a “dump storage” holding random blubs, and not leak users’ data (or metadata).

Thanks, makes sense!