Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security Feature: Error if local / repository nonce are not in agreement -- improve encryption trust #8218

Closed
QUser534 opened this issue May 14, 2024 · 1 comment

Comments

@QUser534
Copy link

Given that borg encryption is based on a trusted setup with the server in the case that the local nonce is lost, then I think it would be useful to error if local / repos nonce is ever out of sync. This can help detect malicious backup servers. Encryption appears to be a major weakness of borg and it's need for a trusted server. This change would remove the need to trust the server and thus make borg encryption far more robust.

Having a "--error-on-nonce-mismatch" option would mean that any time the local / server nonce are not in agreement (not equal because one is missing or of different value), then instead of backup up borg will present a security notice. This would be completely opt-in as only a backup run with "--error-on-nonce-mismatch" would be affected, so it is backwards compatible.

For example, many people use borgbase. There is no easy way to determine if borgbase is serving bad nonces, so people could be getting silently attacked. Of course this could only happen if the local nonce was lost (I assume) which is unlikely in most cases, but better to be safe than sorry by detecting when nonces are not in agreement.

@ThomasWaldmann
Copy link
Member

ThomasWaldmann commented May 14, 2024

The local and server nonce can be easily out of sync, e.g. if you back up with 2 different clients to same repo. Or if you run borg commands on the server also (which would make it client also).

The solution for this will come in borg2, which does not need nonce management any more, because it just uses new session keys for each borg invocation.

Also, I suggest trying the nonce behaviour with borg 1.x practically. The problematic case is if the server suggests an older / lower nonce value than it should (and than the client usually knows locally also) - that would lead to nonce reuse IF the borg client would take that value (which it does not if the local value is higher). IIRC, borg already complains loudly in that case and rejects to work with the repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants