Duplicity

What would be a real-world scenario to prefer public key encryption to the default symmetric encryption?

Asked by Andreas Schmidt

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

Question information

Language:
English Edit question
Status:
Expired
For:
Duplicity Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
edso (ed.so) said : 		#1

a little off topic here, as your question is generally

"What is the advantage of asymmetric encrytion over symmetric using gnupg?"

so everything answering that, answers it with respect to duplicity as well ;). this assumes that a third party has access to the encrypted data only of course.

looks like you are mixing that with what happens if a third party gains access to your system where the encryption/backup happens.

i'd answer as follows: in short, that is the worst case. no backup software can help anymore at that point.
the attacker can modify the data as such. additionally due to access to the backup repo older backups may be modified by the attacker. from that moment on the case is a lost one.
the only preventive measure here is to backup to a location that does not allow the modification of backup data once it's uploaded completely. this way you can safely go back to a point in time where your data was uncorrupted.

..ede/duply.net

Revision history for this message
Andreas Schmidt (remigius42) said : 		#2

Dear ede,

thank you for your quick reply. You are right, by hindsight a lot of my questions are
focusing more on gnupg and its integration into duplicity, than on duplicity itself.

I should probably reformulate my questions:

- Did you or someone else in the team come across a scenario, in which it is useful to not having
  to expose the private encryption key for backups with duplicity?
  This is what I meant when I wrote at the beginning, that I might be missing something obvious:
  I agree with you, that if the system is compromised, the backup is likely to be a lost cause too.
  Therefore, even with all my pondering summarized above, I still struggle to understand, why
  someone would want to go down that rabbit hole.

- Also related to https://lists.launchpad.net/duplicity-team/msg02374.html and the remark
  regarding verifying the backups, what is your or the teams opinion regarding the usage of
  Amazon Glacier, especially because version 0.8 seems to support it out of the box?
  I am aware, that periodical verification of backups is not limited to duplicity as well, the reason
  for this question is, that I am struggling to reconcile this requirement, the statements in
  the linked post and the flag "--s3-use-glacier".

- Finally, if you had the time and leisure to read through my admittedly somewhat circuitous
  insights outlined above, I would be grateful if you let me know, if you think that additional
  aspects are incomplete or incorrect, besides the fact, that the destination would have to be
  "append only" and that it is likely unavailing in any case.

Thank you for your time and thoughts, best regards
Andreas

Revision history for this message
Launchpad Janitor (janitor) said : 		#3

This question was expired because it remained in the 'Open' state without activity for the last 15 days.