Re: duply: Allow to disable gpg key export

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: duply: Allow to disable gpg key export

duplicity-talk mailing list
On 18.07.2017 12:22, Lukas Czerner wrote:

> On Tue, Jul 18, 2017 at 11:52:07AM +0200, [hidden email] 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.

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

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

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.

> as well. But ultimatelly this is your call.

understood, just hesitant, that's all.

>
> Thanks!

no problemo.. ede/duply.net

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: duply: Allow to disable gpg key export

duplicity-talk mailing list
On 18.07.2017 13:39, Lukas Czerner wrote:

> On Tue, Jul 18, 2017 at 12:37:20PM +0200, [hidden email] wrote:
>> On 18.07.2017 12:22, Lukas Czerner wrote:
>>> On Tue, Jul 18, 2017 at 11:52:07AM +0200, [hidden email] 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


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: duply: Allow to disable gpg key export

duplicity-talk mailing list
On 18.07.2017 15:07, Lukas Czerner wrote:

> On Tue, Jul 18, 2017 at 02:17:41PM +0200, [hidden email] wrote:
>> On 18.07.2017 13:39, Lukas Czerner wrote:
>>> On Tue, Jul 18, 2017 at 12:37:20PM +0200, [hidden email] wrote:
>>>> On 18.07.2017 12:22, Lukas Czerner wrote:
>>>>> On Tue, Jul 18, 2017 at 11:52:07AM +0200, [hidden email] 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

_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: duply: Allow to disable gpg key export

duplicity-talk mailing list
On 18.07.2017 15:58, Lukas Czerner wrote:

> On Tue, Jul 18, 2017 at 03:25:23PM +0200, [hidden email] wrote:
>>> 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
>
> It very well may be, but with this simple workaround it works.
>
> export LANG=C

be aware that this is a bug and will lead to inconsistent backups in case the remote is more recent than the local archive cache folder.

if you value your data, which you probably do, as you do backups, you should refrain from using this "workaround".

last I heard about it is that the maintainer is about to remove it finally in the upcoming duplicity 0.8.

>>
>>>>
>>>>> 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
>
> I tend to keep my keys safe myself. So I guess, too bad for me.

not at all. i might add the switch silently w/o promoting it, but i will still need some time to ponder over it. sorry.

>> 2. the profile folder is supposed to be located in a trustworthy location
>
> There are more than two levels of trust and I value my keys more than
> duply configuration.
>
>> 3. because you _do not_ need a personal secret key if the double key approach is used
>
> I do not think that's convenient nor secure enough.
>
> So we have to agree to disagree here, but thanks for your time anyway.

nP.. different heads, different minds. in the end it is you responsible for your or your customers data, so you may treat it as you see fit!

..ede/duply.net


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: duply: Allow to disable gpg key export

duplicity-talk mailing list
I'm confused, is 'duply' shorthand for 'duplicity'? Is duplicity somehow exporting the gpg private key to somewhere else other than where it lives normally (~/.gnupg) ? 

~Mark
On Jul 18, 2017, at 07:15, edgar.soldin--- via Duplicity-talk <[hidden email]> wrote:

On 18.07.2017 15:58, Lukas Czerner wrote:
On Tue, Jul 18, 2017 at 03:25:23PM +0200, [hidden email] wrote:
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

It very well may be, but with this simple workaround it works.

export LANG=C

be aware that this is a bug and will lead to inconsistent backups in case the remote is more recent than the local archive cache folder.

if you value your data, which you probably do, as you do backups, you should refrain from using this "workaround".

last I heard about it is that the maintainer is about to remove it finally in the upcoming duplicity 0.8.



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

I tend to keep my keys safe myself. So I guess, too bad for me.

not at all. i might add the switch silently w/o promoting it, but i will still need some time to ponder over it. sorry.

2. the profile folder is supposed to be located in a trustworthy location

There are more than two levels of trust and I value my keys more than
duply configuration.

3. because you _do not_ need a personal secret key if the double key approach is used

I do not think that's convenient nor secure enough.

So we have to agree to disagree here, but thanks for your time anyway.

nP.. different heads, different minds. in the end it is you responsible for your or your customers data, so you may treat it as you see fit!

..ede/duply.net


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk
Reply | Threaded
Open this post in threaded view
|

Re: duply: Allow to disable gpg key export

duplicity-talk mailing list
On 18.07.2017 17:59, Mark Grandi wrote:
> I'm confused, is 'duply' shorthand for 'duplicity'?

nope, it's a frontend for duplicity. an extra program helping you to run duplicity conveniently.

> Is duplicity somehow exporting the gpg private key to somewhere else other than where it lives normally (~/.gnupg) ?

no. duplicity does not!

duply however does by exporting copies of the used keys into the profile folder, which usually live under ~/.duply/ or /etc/duply/. duply tells you when it uses a key for the first time and that it just exported it to the profile folder and that you should backup your profile again as it now contains additional keys.
it does so to help you keep _all_ data needed to restore your backup. all you need to do is keeping a copy of your profile folder somewhere safe.

..ede/duply.net


_______________________________________________
Duplicity-talk mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk