From 668a136794a4c2bc07e9db906abf50ee0b0fcb86 Mon Sep 17 00:00:00 2001 From: Thalian Date: Thu, 23 Jul 2020 20:40:53 +0200 Subject: [PATCH] docs: add security faq explaining AES-CTR crypto issues, fixes #5254 --- docs/faq.rst | 33 +++++++++++++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) diff --git a/docs/faq.rst b/docs/faq.rst index 5585d7d09..44caf23de 100644 --- a/docs/faq.rst +++ b/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 *not recommended* from the security perspective. BorgBackup is 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 needs to keep a local cache containing checksums of all file @@ -343,7 +344,7 @@ such math but it's honestly better that you read it yourself and grab your own resolution from that. Assuming that all your chunks have a size of :math:`2^{21}` bytes (approximately 2.1 MB) -and we have a "perfect" hash algorithm, we can think that the probability of collision +and we have a "perfect" hash algorithm, we can think that the probability of collision would be of :math:`p^2/2^{n+1}` then, using SHA-256 (:math:`n=256`) and for example we have 1000 million chunks (:math:`p=10^9`) (1000 million chunks would be about 2100TB). The probability would be around to 0.0000000000000000000000000000000000000000000000000000000000043. @@ -420,6 +421,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?