@@ -386,3 +386,43 @@ and thus no problem in practice.
386
386
No matter what, there is always the option not to use compression if you are worried about this.
387
387
388
388
.. _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