duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Duplicity-talk] Duplicity + asymmetric encryption


From: Marko Božiković
Subject: [Duplicity-talk] Duplicity + asymmetric encryption
Date: Sun, 2 Aug 2015 22:41:31 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

Hi all,

I've started playing with Duplicity for my cloud backup needs and I have a few
questions regarding asymmetric encryption with gpg. Apologies for a long mail,
but I'm confused by Duplicity's behaviour.

I'm using Debian Jessie, duply 1.9.2, duplicity 0.7.3 and gpg 2.1.6 (these are
installed from testing/experimental repos)

I've created a symbolic link gpg->gpg2 in order to force duplicity to use gpg2.

I have a gpg2 keyring setup with a master 4096 bit key, three 2048 bit subkeys
(for signing, encryption and authentication) for everyday use that are stored
on a smart card and a newly created 2048 bit (S, E) subkey for duplicity backup.

I keep my secret master key offline. The keyring on my laptop only contains
the master public key and stubs for secret subkeys that live on the smartcard.
The keyring on my backup machine only contains the public master key and the
duplicity backup subkey.

Here are the relevant bits from my duply config (I've replaced my backup key's
fingerprint with YYYYYYYY:

GPG_KEY='YYYYYYYY'
GPG_OPTS='--pinentry-mode loopback'
VOLSIZE=250
DUPL_PARAMS="$DUPL_PARAMS --volsize $VOLSIZE "
DUPL_PARAMS="$DUPL_PARAMS --file-prefix-archive=backup-data-
--file-prefix-manifest=includes- --file-prefix-signature=signatures-"

Gpg 2.1 always uses gpg-agent for secret key access and it doesn't set
GPG_AGENT_INFO env. variable. This is the output I get when I run duply with
no GPG_AGENT_INFO set (YYYYYYYY is my backup key's fingerprint and XXXXXXXX is
my master key fingerprint)

-------------------------------
-- BEGIN no GPG_AGENT_INFO set
-------------------------------
Start duply v1.9.2, time is 2015-08-02 22:02:48.
Using profile '/home/bozho/.duply/photo'.
Using installed duplicity version 0.7.03, python 2.7.10, gpg 2.1.6 (Home:
~/.gnupg), awk 'mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan', grep
'(GNU grep) 2.20', bash '4.3.30(1)-release (x86_64-pc-linux-gnu)'.
Autoset found secret key of first GPG_KEY entry 'YYYYYYYY' for signing.
Cannot use gpg-agent. GPG_AGENT_INFO not set.
Checking TEMP_DIR '/tmp' is a folder (OK)
Checking TEMP_DIR '/tmp' is writable (OK)
Enter passphrase: <MY SECRET KEY PASSWORD>
Test - Encrypt to 'YYYYYYYY' & Sign with 'YYYYYYYY' (OK)
Test - Decrypt (OK)
Test - Compare (OK)
Cleanup - Delete '/tmp/duply.1629.1438549369_*'(OK)
Export SEC key 'YYYYYYYY' (FAILED)

WARNING:

Backup failed.
gpg: key XXXXXXXX/YYYYYYYY: error receiving key from agent: No passphrase
given - skipped

Export SEC key 'YYYYYYYY' (FAILED)

WARNING:

Backup failed.
gpg: key XXXXXXXX/YYYYYYYY: error receiving key from agent: No passphrase
given - skipped


--- Start running command PRE at 22:03:14.018 ---
Skipping n/a script '/home/bozho/.duply/photo/pre'.
--- Finished state OK at 22:03:14.122 - Runtime 00:00:00.103 ---

--- Start running command BKP at 22:03:14.135 ---
Reading globbing filelist /home/bozho/.duply/photo/exclude
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
GnuPG passphrase: <ANY PASSPHRASE>
GnuPG passphrase for signing key: <MY SECRET KEY PASSWORD>
No signatures found, switching to full backup.
-------------------------------
-- END no GPG_AGENT_INFO set
-------------------------------


Note that I get asked a passphrase three times:

- "Enter passphrase", which requires my secret backup subkey password - why is
that needed here?

- "GnuPG passphrase:", which can be any password - I'm guessing that's used as
the session key that actually encrypts the data and then gets encrypted by my
public subkey. Why is this necessary? In OpenPGP, the session key can/should
be a long random key - the recipient doesn't need to know it.

- "GnuPG passphrase for signing key" - ok, this one is for signing, since it's
enabled and I'm using the same key.



Now, if I restart gpg-agent in order to reset its caching and actually export
GPG_AGENT_INFO, I get a slightly different output:

-------------------------------
-- BEGIN GPG_AGENT_INFO set
-------------------------------
Start duply v1.9.2, time is 2015-08-02 22:12:42.
Using profile '/home/bozho/.duply/photo'.
Using installed duplicity version 0.7.03, python 2.7.10, gpg 2.1.6 (Home:
~/.gnupg), awk 'mawk 1.3.3 Nov 1996, Copyright(C) Michael D. Brennan', grep
'(GNU grep) 2.20', bash '4.3.30(1)-release (x86_64-pc-linux-gnu)'.
Autoset found secret key of first GPG_KEY entry 'YYYYYYYY' for signing.
Autoenable use of gpg-agent. GPG_PW or GPG_PW_SIGN (enc != sign key) not set.
Checking TEMP_DIR '/tmp' is a folder (OK)
Checking TEMP_DIR '/tmp' is writable (OK)
Enter passphrase: <MY SECRET KEY PASSWORD>
Test - Encrypt to 'YYYYYYYY' & Sign with 'YYYYYYYY' (OK)
Test - Decrypt (OK)
Test - Compare (OK)
Cleanup - Delete '/tmp/duply.4740.1438549962_*'(OK)
Export SEC key 'YYYYYYYY' (FAILED)

WARNING:

Backup failed.
gpg: key XXXXXXXX/YYYYYYYY: error receiving key from agent: No passphrase
given - skipped

Export SEC key 'YYYYYYYY' (FAILED)

WARNING:

Backup failed.
gpg: key XXXXXXXX/YYYYYYYY: error receiving key from agent: No passphrase
given - skipped


--- Start running command PRE at 22:13:22.870 ---
Skipping n/a script '/home/bozho/.duply/photo/pre'.
--- Finished state OK at 22:13:22.956 - Runtime 00:00:00.085 ---

--- Start running command BKP at 22:13:22.966 ---
Reading globbing filelist /home/bozho/.duply/photo/exclude
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
No signatures found, switching to full backup.
-------------------------------
-- END GPG_AGENT_INFO set
-------------------------------

Notice that I get asked for a password only once, at the beginning ("Enter
passphrase") Why is that, and is the session key being randomly generated in
this case or is my secret subkey password used as a session key (this is a bad
idea)

Thank you,
-- 
Marko



reply via email to

[Prev in Thread] Current Thread [Next in Thread]