|
|
@@ -27,7 +27,13 @@ which is slower.
|
|
|
Can I backup from multiple servers into a single repository?
|
|
|
------------------------------------------------------------
|
|
|
|
|
|
-Yes, but in order for the deduplication used by |project_name| to work, it
|
|
|
+Yes, this is *possible* from the technical standpoint, but it is
|
|
|
+*not recommended* from the security perspective. |project_name| is
|
|
|
+built upon a defined :ref:`attack_model` that cannot provide its
|
|
|
+guarantees for multiple clients using the same repository. See
|
|
|
+:ref:`borg_security_critique` for a detailed explanation.
|
|
|
+
|
|
|
+Also, in order for the deduplication used by |project_name| to work, it
|
|
|
needs to keep a local cache containing checksums of all file
|
|
|
chunks already stored in the repository. This cache is stored in
|
|
|
``~/.cache/borg/``. If |project_name| detects that a repository has been
|
|
|
@@ -353,6 +359,34 @@ to change them.
|
|
|
Security
|
|
|
########
|
|
|
|
|
|
+.. _borg_security_critique:
|
|
|
+
|
|
|
+Isn't BorgBackup's AES-CTR crypto broken?
|
|
|
+-----------------------------------------
|
|
|
+
|
|
|
+If a nonce (counter) value is reused, AES-CTR mode crypto is broken.
|
|
|
+
|
|
|
+To exploit the AES counter management issue, an attacker would need to have
|
|
|
+access to the borg repository.
|
|
|
+
|
|
|
+By tampering with the repo, the attacker could bring the repo into a state so
|
|
|
+that it reports a lower "highest used counter value" than the one that actually
|
|
|
+was used. The client would usually notice that, because it rather trusts the
|
|
|
+clientside stored "highest used counter value" than trusting the server.
|
|
|
+
|
|
|
+But there are situations, where this is simply not possible:
|
|
|
+
|
|
|
+- If clients A and B used the repo, the client A can only know its own highest
|
|
|
+ CTR value, but not the one produced by B. That is only known to (B and) the
|
|
|
+ server (the repo) and thus the client A needs to trust the server about the
|
|
|
+ value produced by B in that situation. You can't do much about this except
|
|
|
+ not having multiple clients per repo.
|
|
|
+
|
|
|
+- Even if there is only one client, if client-side information is completely
|
|
|
+ lost (e.g. due to disk defect), the client also needs to trust the value from
|
|
|
+ server side. You can avoid this by not continuing to write to the repository
|
|
|
+ after you have lost clientside borg information.
|
|
|
+
|
|
|
.. _home_config_borg:
|
|
|
|
|
|
How important is the $HOME/.config/borg directory?
|
Thalian