mirror of
https://github.com/borgbackup/borg.git
synced 2025-02-19 04:41:50 +00:00
documented secret key usage against fingerprinting (#6345)
docs: secret key usage against fingerprinting Co-authored-by: Thomas Waldmann <tw@waldmann-edv.de>
This commit is contained in:
parent
0e3ff0ab70
commit
c85bcfd3ad
1 changed files with 18 additions and 0 deletions
|
@ -520,6 +520,24 @@ To summarize, this is making size-based fingerprinting difficult:
|
|||
- optional ``obfuscate`` pseudo compressor with different choices
|
||||
of algorithm and parameters
|
||||
|
||||
Secret key usage against fingerprinting
|
||||
---------------------------------------
|
||||
|
||||
Borg uses the borg key also for chunking and chunk ID generation to protect against fingerprinting.
|
||||
As usual for borg's attack model, the attacker is assumed to have access to a borg repository.
|
||||
|
||||
The borg key includes a secret random chunk_seed which (together with the chunking algorithm)
|
||||
determines the cutting places and thereby the length of the chunks cut. Because the attacker trying
|
||||
a chunk length fingerprinting attack would use a different chunker secret than the borg setup being
|
||||
attacked, they would not be able to determine the set of chunk lengths for a known set of files.
|
||||
|
||||
The borg key also includes a secret random id_key. The chunk ID generation is not just using a simple
|
||||
cryptographic hash like sha256 (because that would be insecure as an attacker could see the hashes of
|
||||
small files that result only in 1 chunk in the repository). Instead, borg uses keyed hash (a MAC,
|
||||
e.g. HMAC-SHA256) to compute the chunk ID from the content and the secret id_key. Thus, an attacker
|
||||
can't compute the same chunk IDs for a known set of small files to determine whether these are stored
|
||||
in the attacked repository.
|
||||
|
||||
Stored chunk proximity
|
||||
----------------------
|
||||
|
||||
|
|
Loading…
Reference in a new issue