Skip to content

Commit ecb93ff

Browse files
Merge pull request #3720 from ThomasWaldmann/fingerprinting-docs-1.1
security: describe chunk size / proximity issue, see #3687
2 parents 8c40c19 + f3465c7 commit ecb93ff

File tree

1 file changed

+40
-0
lines changed

1 file changed

+40
-0
lines changed

docs/internals/security.rst

+40
Original file line numberDiff line numberDiff line change
@@ -386,3 +386,43 @@ and thus no problem in practice.
386386
No matter what, there is always the option not to use compression if you are worried about this.
387387

388388
.. _github issue #1040: https://github.com/borgbackup/borg/issues/1040
389+
390+
Fingerprinting
391+
==============
392+
393+
Stored chunk sizes
394+
------------------
395+
396+
A borg repository does not hide the size of the chunks it stores (size
397+
information is needed to operate the repository).
398+
399+
The chunks stored are the (compressed and encrypted) output of the chunker,
400+
chunked according to the input data, the chunker's parameters and the secret
401+
chunker seed (which all influence the chunk boundary positions).
402+
403+
Small files below some specific threshold (default: 512kiB) result in only one
404+
chunk (identical content / size as the original file), bigger files result in
405+
multiple chunks.
406+
407+
After chunking is done, compression, encryption and authentication are applied,
408+
which influence the sizes of the chunks stored into the repository.
409+
410+
Within our attack model, an attacker posessing a specific set of files which
411+
he assumes that the victim also posesses (and backups into the repository)
412+
could try a brute force fingerprinting attack based on the chunk sizes in the
413+
repository to prove his assumption.
414+
415+
Stored chunk proximity
416+
----------------------
417+
418+
Borg does not try to obfuscate order / proximity of files it discovers by
419+
recursing through the filesystem. For performance reasons, we sort directory
420+
contents in file inode order (not in file name alphabetical order), so order
421+
fingerprinting is not useful for an attacker.
422+
423+
But, when new files are close to each other (when looking at recursion /
424+
scanning order), the resulting chunks will be also stored close to each other
425+
in the resulting repository segment file(s).
426+
427+
This might leak additional information for the chunk size fingerprinting
428+
attack (see above).

0 commit comments

Comments
 (0)