duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] Questions regarding symmetric encryption/signing


From: edgar . soldin
Subject: Re: [Duplicity-talk] Questions regarding symmetric encryption/signing
Date: Thu, 25 Jun 2015 15:01:27 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 25.06.2015 14:33, Eponymous - wrote:
>>> duplicity utilizes the command line binary gpg which only supports piping 
>>> on passphrase. so both of the above is true.
> if no key is given the passphrase is used for symmetric de/encryption.
> if one is givenit's used to unlock the keys for decryption or signing.
> 
> I still don't see how in the symmetric role of operation this marries
> up with how GPG works: "Both PGP and GnuPG use hybrid ciphers. The
> session key, encrypted using the public-key cipher, and the message
> being sent, encrypted with the symmetric cipher, are automatically
> combined in one package. The recipient uses his private-key to decrypt
> the session key and the session key is then used to decrypt the
> message." [1]

my above was speaking with duplicity in mind.

> Or are you saying that if we don't give a key, then we don't use GPG
> at all and instead the data is raw encrypted using the PASSPHRASE as a
> key to some internal encryption engine in Duplicity?

no. for all encryption in duplicity gpg is utilized.
 
> 
>>> let me point you to "a Note on Symmetric Encryption and Signing" 
>>> http://duplicity.nongnu.org/duplicity.1.html#sect24 which seems to have 
>>> slipped your man page reading ;)
> 
> I did  read this over a few times before asking and it still didn't
> make sense to me. For example, it states:

then you should point out the unclear parts ;)

> "3. The used PASSPHRASE for symmetric encryption and the passphrase of
> the signing key are identical. "
> 
> What does this mean? Is it referring to the PASSPHRASE env variable
> used to protect the GPG keys? How does the SIGN_PASSPHRASE env
> variable play into this?

for symmetric encryption _no_ keys are used. for signed symmetric encrytion you 
need a passphrase and a secret key. you can however only pipe _one_ passphrase 
into gpg, hence both passphrases need to be identical.

SIGN_PASSPHRASE was introduce to mitigate the issue above for signed key 
encryption. especially if you choose a different key for signing than for 
encryption.

for servers i would suggest you to use gpg-agent , which is a little bit more 
complicated to set up, but the most secure setup avail. of course you will have 
to do manual backup everytime the machine is rebooted for the passphrases to be 
read into memory again.
 
> 
>>> how about using http://duply.net which takes care to generate the proper 
>>> command lines for you?
> 
> I think it's more that I think some of the references to
> command-lines/env variables are confusing.

well, if you find ways to improve duplicity documentation your more than 
welcome.

> 
> For example:
> 
> "--encrypt-key key-id When backing up, encrypt to the given public
> key, instead of using symmetric (traditional) encryption. Can be
> specified multiple times. The key-id can be given in any of the
> formats supported by GnuPG; see gpg(1) , section "HOW TO SPECIFY A
> USER ID" for details. "
> 
> I'd say that's not a helpful choice of name there :) From reading:
> "--encrypt-key" it's not obvious that this only applies to
> public/private keypair encryption.

well it says _key_ in the name and you are the first to complain. you cannot do 
symmetric encryption against keys. also it clearly says what happens if this 
parameter is not set.

sorry, i don't see the issue here ;(

> 
> Again, sorry if these seem like obvious questions but Duplicity looks
> to be perfect for my needs seems like it's worth the effort of getting
> a deep understanding :)
> 

it's a nifty piece of software. agreed. and exactly because it is difficult to 
get the parameters right i co-developed ftplicity now duply.

..ede/duply.net




reply via email to

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