duplicity-team team mailing list archive

[Andreas Schmidt <question689862@xxxxxxxxxxxxxxxxxxxxx>]

New question #689862 on Duplicity:
https://answers.launchpad.net/duplicity/+question/689862

Dear all,

after some pondering about the following, I decided to ask it here,
as well as to share my thoughts, because I might be missing something obvious.

tl;dr What would be a real-world scenario to prefer public key
encryption to the default symmetric cipher when using duplicity,
except not having to share a passphrase with multiple destinations?

----

By my understanding of the code, duplicity uses gnupg with the option
"--symmetric" if there are no recipients given:
https://bazaar.launchpad.net/~duplicity-team/duplicity/0.8-series/view/head:/duplicity/gpg.py#L195
For current versions of gnupg, this should result in AES-256 being used.
If there are recipients, an AES-256 key will be generated and encrypted
with the public key cipher and the payload should be encrypted with AES-256
as well.

Looking for answers I came across
- https://bugs.launchpad.net/duplicity/+bug/687295 about backups without private keys
- https://answers.launchpad.net/duplicity/+question/109976 about multiple public keys
- https://lists.launchpad.net/duplicity-team/msg02374.html about why backups without
  a private key might be a bad idea.

Particularly when reading the last post, I also started to wonder, under
which circumstances it would be of any benefit, to not have to expose the
private key, if an attacker already has direct access to the data anyway.

The insights I managed to come up with so far are the following:
- Using public keys to encrypt the backup simplifies encryption to multiple
  parties without having to share a passphrase via a secure channel first.
  That a passphrase would be shared should IMHO not be that much of a
  problem, because I trust these parties with the data as well.
- If I assume, that the machine of which the backups are created by duplicity
  has some host-based intrusion detection system (HIDS) running, which would raise
  an alert if a large amount of data would be transmitted somewhere else except
  the backup destination and additionally the HIDS at least has some chance
  of eventually detecting unauthorized access, it might make a difference, 
  if there is no plain passphrase in a script and no private key available 
  to decrypt the backup (should the attacker actually be able to access the backup).
  Even though the attacker has access to the source data, stealing or
  exploiting all of it might be prevented.
- Because the attacker will have access to the signing key (or at least I
  do not see how this could be prevented), the backups could be tampered
  with, which could lead to additional attack vectors.
  However, still assuming the effectiveness of the HIDS, at least it would
  be possible to roll back the backup to the time before the breach.
- The issue regarding being unable to verify the backups without the
  private key raised in https://lists.launchpad.net/duplicity-team/msg02374.html
  might be circumvented via gpg-agent forwarding from a trusted machine,
  thereby forwarding the private encryption key.
  Admittedly, to some extent this only shifts the problem to another host.
- Slightly off-topic, would this aforementioned verify issue not render
  backups to services like Amazon Glacier more or less unavailing?
  By my understanding, the pricing scheme of such services precludes the
  usage of "duplicity verify", but if I should verify periodically to
  ensure my backup is still usable or run at risk of not being able to
  use it when I most need it, what is the use of having a backup on such a
  service in the first place?
- If I am really that concerned about the security of the host of which
  duplicity creates backups and the security of these backups, would I
  accept the trade-off of using eg. RSA-4096 vs. AES-256?
  If the asymmetric encryption is broken, which as far as I am aware, might be
  more likely than breaking AES-256, the backup is exposed.
- In order to mitigate this, I could rotate the asymmetric encryption
  subkeys, such that in order to get access to the complete backup, the 
  encryption would have to be broken multiple times.
  This could improve backup security and I do not think something similar
  is possible with the default symmetric encryption.


Thank you for your thoughts and best regards
Andreas

-- 
You received this question notification because your team duplicity-team
is an answer contact for Duplicity.