Re: [Duplicity-talk] duply: Allow to disable gpg key export

[edgar . soldin]

On 18.07.2017 15:07, Lukas Czerner wrote:
> On Tue, Jul 18, 2017 at 02:17:41PM +0200, address@hidden wrote:
>> On 18.07.2017 13:39, Lukas Czerner wrote:
>>> On Tue, Jul 18, 2017 at 12:37:20PM +0200, address@hidden wrote:
>>>> On 18.07.2017 12:22, Lukas Czerner wrote:
>>>>> On Tue, Jul 18, 2017 at 11:52:07AM +0200, address@hidden wrote:
>>>>>> On 17.07.2017 17:25, Lukas Czerner wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am a new user of the duply script and I quite like it, however before
>>>>>>> I can seriously use this I have to disable the key export. I do not want
>>>>>>> my keys to be scattered all over the place, I need to keep them in one
>>>>>>> location only. I hope you choose to apply this.
>>>>>>>
>>>>>>
>>>>>> well, security-wise this makes no sense, as an attacker who has access 
>>>>>> to your box may access both locations. convenience-wise it is practical 
>>>>>> as you only need to keep your profile folder safe and it will contain 
>>>>>> all the keys you need to restore your data to another box.
>>>>>
>>>>> Hi,
>>>>
>>>> Lukas,
>>>>  
>>>> i'll forward this to the duplicity ml too, just in case somebody wants to 
>>>> chime in over there.
>>>
>>> Sure, I am not subscribed to that ml, so anyone replying please reply to
>>> me as well.
>>>
>>>>
>>>>> security wise it does make a lot of sense. You need to know where your
>>>>> keys are stored in order to make sure it's not accidentally exposed.
>>>>> This is very hard to do in situation where your application (and
>>>>> possibly others) copy your keys around.
>>>>>
>>>>> Now practically, I am using different backup and sync solutions and I want
>>>>> to make sure my keys are not included in any of those unless I
>>>>> specifically choose to. Your approach makes it more inconveniet to me,
>>>>
>>>> your duply profiles probably contain sensitive data (backend credentials, 
>>>> key passphrase) anyway. where are the profiles located in your system? if 
>>>> they are in the standard locations (/etc/duply, ~/.duply) i don't see the 
>>>> advantage of the switch, as the keys are instrumental to restoring, but 
>>>> may get lost if they were not explicitly bundled with the profile.
>>>
>>> There are degrees of sensitiveness, my private keys are on top. And
>>
>> that's why i tell you that you don't need your private secret key to operate 
>> duplicity
>>
>>> while I feel comfortable putting those config files to some sort of
>>> trusted encrypted cloud storage I can't say the same about my keys.
>>
>> except your public key, that's why it's called a public key :)
> 
> No, you need both. Public to encrypt and private to decrypt. And your
> script exports both, so I do not see your point here.

easy. assuming you'd encrypt your backup using a machine public _and_ 
additionally your own public key, you will only need the machine's secret key 
to locally decrypt if need arises (synchronize archive dir, resume backup, 
restore, verify ...).

you will still be able to decrypt using your own secret key, as a fallback in 
case you loose the machine key pair for some reason (hardware, human fault etc.)
 
>>
>>> Ideally they will not be on my PC at all, but rather on yubikey or
>>> similar thing.
>>>
>>>>
>>>>> so I disabled it on my system and I think others might benefit from this
>>>>
>>>> there is the chance one deactivated it and forgot about it and will be 
>>>> unable to restore because of missing keys.
>>>
>>> Some human errors you just can't prevent :)
>>
>> we can try though ;)
>>
>>>>
>>>> btw. if you are using your personal secret key to sign and decrypt the 
>>>> backup, that's bad practice. consider using a passphraseless machine key 
>>>> pair for en/decryption and additionally add your personal public key as 
>>>> key to encrypt against.
>>>> that way only the machine key pair and your personal _public_ key will end 
>>>> up in the profile.
>>>
>>> Why is it bad practice ? 
>>
>> exactly because you need a secret key to decrypt when synchronizing the 
>> archive dir and you might not want to expose your private secret key.
> 
> That does not make sense to me. You need it to decrypt, yes. But I'd not
> expose it if your script did not export it to it's own location.

sorry, dunno what you mean here

> Btw, you should not need to decrypt when synchronizing the archive
> except for some special cases IIRC.

_wrong_ that's an outstanding bug (since 2010) in duplicity
  https://bugs.launchpad.net/duplicity/+bug/687295

>>
>>> I want to only have one so I minimize a chance
>>> of losing, or exposing it. I'd argue that passphraseless key pairs are
>>> bad practice though.
>>
>> depends.. in this scenario you will have to provide the passphrase along 
>> with the secret key anyway, so it is up to you, if you generate the machine 
>> key pair, w/ or w/o passphrase.
>> the gist is that this keypair identifies (signs) and encrypts specific to 
>> this machine and the key is used for nothing else. an attacker already on 
>> your machine can modify your data/decrypt your backup/delete files on the 
>> backend etc. anyway.
>>
>> the dual key approach is merely there to protect your private secret key, as 
>> duplicity needs a secret key for decryption sometimes.
> 
> To protect it from what ? 

from attackers gaining access to it. as you said, ideally it is not physically 
located on the machine but on a keycard or such. 

>Are you telling me that duplicity can't be trusted
> with my passphrase for the secret key ?

as much as gpg can be trusted w/ it, as duplcity is merely using the gpg cmd 
line binary.

> Again, this is not about attacker getting to my machine. It's about
> keeping track of my keys. Look at it this way, if every program would
> export my private keys to it's own location, that would be a horrible
> mess - so why should you script be an exception ?

1. because users will need those keys at some point, but tend to setup and 
forget
2. the profile folder is supposed to be located in a trustworthy location
3. because you _do not_ need a personal secret key if the double key approach 
is used

..ede/duply.net