8

The top answer to this question and the article it references explain that when an adversary can see snapshots of a Truecrypt container over time, the encryption is weakened. That same answer suggests that duplicity may be a better solution to the problem of storing encrypted data on a remote server.

I wanted to ask whether anyone could explain this in a bit more detail. The duplicity backup model uses a full backup, followed by backups of incremental changes. From a security point of view, is this a clear improvement on backing up successive snapshots? Does the duplicity model have other weaknesses? (I mean strictly from a cryptographic security perspective: excluding time to recover backups, storage space, bandwidth, etc.)

SauceCode
  • 628
  • 6
  • 16

1 Answers1

5

From a strictly cryptographic sense, the Duplicity model does not have any weaknesses.

Duplicity is designed specifically for a threat model when the destination server is untrusted. It drastically improves incremental backups, because rather than transferring a diff of the already encrypted data, it sends new encrypted files, with a new key. There is no way to tell that one given incremental snapshot and another from a later date have any similarities. Each snapshot is a fixed size (25 MiB by default). From the perspective of an attacker, a new snapshot could hold 25 MiB worth of entirely new files, 25 MiB worth of incremental changes, or even 25 MiB worth of metadata (file deletion records and such). This is in contrast with a block device using XTS mode which tends to leak information when changes over time can be monitored.

Duplicity additionally signs files using GnuPG, which provides an integrity guarantee. XTS mode is often considered "poor-man's malleability resistance", but it really is very poor at that, allowing modifications with 16 byte precision. Duplicity's digital signatures ensure that even a single changed bit will be detected, even when using CBC mode.

Duplicity's backups are done in several stages:

  • rsync is used to compare differences between a cached record of files and your filesystem
  • tar is used to archive 25 MiB worth of incremental changes into a single file
  • gpg is used to encrypt and sign the tarball
  • the encrypted tarball is sent to the destination server all at once

While XTS mode provides a lot of information when changes over time are observed, all the destination server can see with duplicity is the amount of data changed. Say you take a 50 MiB file, back it up, then you modify half of it before backing it up incrementally again. If this is done with XTS, the precise areas which have been modified are visible. With duplicity, what you see is 2 encrypted 25 MiB files, and then later another encrypted 25 MiB file. You cannot compare the first backup with the second incremental backup to see what data changed. All you can see is how much changed.

The precise information the untrusted server can observe with duplicity is very limited:

  • the total amount of data stored
  • the amount of data transferred in each backup (roughly corresponding to the number of changes)
  • the approximate size of the total stored data (due to periodic non-incremental full backups)
forest
  • 64,616
  • 20
  • 206
  • 257