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

[edgar . soldin]

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 :)

> 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.

>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.

..ede/duply.net