borg2: remove unencrypted / authenticated modes?

[ThomasWaldmann]

supporting encrypted and unencrypted repos adds some complexity and it would be good if we could get rid of that, e.g. the code dealing with tam_required(its value is only False for unencrypted repos or very old repos, which will be gone when we migrate to borg2).

Since quite a while, the docs recommend against using --encryption none and favour --encryption authenticated (which is authenticated, but also not encrypted) instead of that, so the user is able to at least verify the authenticity of the data by checking a MAC (strong cryptographic checksum, computed with a secret key) - even if they did not enable encryption for some reason.

But: authenticated already requires having to deal with a borg key to store the MAC secret, so the question is why one would use that and not just use authenticated encryption?

CPUs nowadays usually are super fast and often have AES hw acceleration and even those which don't have that could use chacha20-poly1305 in borg2, which is pure software and still very fast.

Considering that the user can't access the borg repo directly (e.g. to directly access backed up files like they could with a rsync copy) because borg chunks the files and stores them into numbered segment files, what's the advantage of none and authenticated modes anyway?

If you use none or authenticated, let's discuss below.

Note: as borg2 is a breaking change and repos need to be transferred with borg transfer anyway, we could encrypt/authenticate archives from unencrypted borg1 repos when doing that.

[SanskritFritz]

I would prefer simplicity of code. That usually means less bugs and performance issues. Getting rid of no encryption is a price I would gladly pay for simplicity and of course more security.

[jdchristensen]

I use none, and have a mild preference for being able to continue this. I control the servers I back up to, and prefer to have one fewer thing that can go wrong (losing a key) if I need to recover from backups. I'm also avoiding some code paths, and saving some cpu time.

[pwaring]

I use none, and would prefer to continue. I do so for two reasons:

1. I backup exclusively to removable media which have LUKS, therefore there's not much point in adding another layer of encryption.
2. Borg is the slowest of the backup software I use (especially borg check) and presumably encryption would increase the time required further. I have some older and less performant devices to backup as well - whilst my desktop CPUs probably have hardware AES support, this is not the case for all my devices.

The other backup software I use are restic (takes about 10% of the time of borg create + check) and tar. If borg2 mandated encryption then I would have to assess the performance - at the moment it's pretty painful when I run borg check (which I only do every 7 days because of this) and any additional slowdown would likely make me drop it.

[sebsauvage]

In some cases, I really do not want borg to take care of security. Some examples :

• Some of my backups are on a VeraCrypt volume. I do not need borg additional protection for this.
• I sometimes use Borg to keep a (compressed) history of local files. I do not need borg to encrypt anything.

In these cases, having to backup a key would add a burden.

[RonnyPfannschmidt]

@ThomasWaldmann im wondering if it would/could make sense to enable deriving authentication from ssh keys and putting the pubkeys into the repo

i do like to have local repos on encrypted external drives where i want to avoid the extra encryption cost on certain hardware (rpi4 is constrainted)

as for the no encryption - i do wonder, if openssh authenticated null cyphers may be a viable option to keep the api the same (i just stumbled uppon them on a manapage, i havent validated if they sensibly apply to borg)

[ThomasWaldmann]

ok, considering the feedback here and on social media, guess we need to keep these modes.

most of the reasons were rather preferences / feelings / assumptions than "hard facts" though.