mirror of https://github.com/borgbackup/borg.git
docs: add security faq explaining AES-CTR crypto issues, fixes #5254
This commit is contained in:
parent
303c11f245
commit
668a136794
31
docs/faq.rst
31
docs/faq.rst
|
@ -30,7 +30,8 @@ Can I backup from multiple servers into a single repository?
|
||||||
Yes, this is *possible* from the technical standpoint, but it is
|
Yes, this is *possible* from the technical standpoint, but it is
|
||||||
*not recommended* from the security perspective. BorgBackup is
|
*not recommended* from the security perspective. BorgBackup is
|
||||||
built upon a defined :ref:`attack_model` that cannot provide its
|
built upon a defined :ref:`attack_model` that cannot provide its
|
||||||
guarantees for multiple clients using the same repository.
|
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 Borg to work, it
|
Also, in order for the deduplication used by Borg to work, it
|
||||||
needs to keep a local cache containing checksums of all file
|
needs to keep a local cache containing checksums of all file
|
||||||
|
@ -420,6 +421,34 @@ to change them.
|
||||||
Security
|
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:
|
.. _home_config_borg:
|
||||||
|
|
||||||
How important is the $HOME/.config/borg directory?
|
How important is the $HOME/.config/borg directory?
|
||||||
|
|
Loading…
Reference in New Issue