Merge pull request #5262 from fantasya-pbem/1.1-maint

docs: add security faq explaining AES-CTR crypto issues, fixes #5254

docs/faq.rst

@@ -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?

docs/internals/security.rst

@@ -13,6 +13,8 @@ Security
 Cryptography in Borg
 ====================
 
+.. _attack_model:
+
 Attack model
 ------------