Re: [Duplicity-talk] Encryption password selection

[Cláudio Gil]

Hi,

First, for me "secure" means "inability of others to decrypt the volumes in the remote storage". So, I was not trying to start a public-key vs symmetric debate. I was basically curious if, by using a RSA key pair, the remote volumes would be harder to decrypt for "equivalent" bit lengths (for example AES 128 and RSA 4096). 

The ability to use two different keys for encryption and signing is interesting and I will consider it, although it seems a marginal improvement in security, for me,

A note on my setup.

The backup system (where duplicity resides) has access to the plain files that are being backed up and is physically near those files. This means that if the system is compromised (my home) the encryption is irrelevant. It is almost as easy to physically carry the hard drives with the original data as it is to get the encryption keys. That is why I'm mostly concerned with the security of the volumes, manifests and sigtars in the remote storage.

Cheers,

Cláudio

 

2014-12-08 23:48 GMT+00:00 Duplicity Mailing List <address@hidden>:

On 08/12/14 19:58, Cláudio Gil wrote:
> 2014-12-08 18:55 GMT+00:00 Duplicity Mailing List
> <address@hidden <mailto:address@hidden>>:
>
>
>     If you're storing your passphrase in a file, nor are planning to
>     actually remember the passphrase, why not use a keyfile? Seems
>     infinitely more logical (and secure).
>
>
> I'm curious. Why would you say that a keyfile is more secure?
>
> Cheers,
> Cláudio
>
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

1. Can be encrypted, securely, without the private key ever coming out
to play*.
2. Only the signing key needs to be on the PC, encryption key can be
stored safely offline*.
3. A keyfile (2048, 4096, or whatever bit key) is probably harder to
brute force than whatever a human would pick, which normally ends up
being "p455w0rd123", "TheQuickBrownFoxJumpedOverTheLazyDog554" or
"aparalyseddonkeypassingbykickedtheblindmanintheeye".

*I don't do this, but, I just tested it, it seems to work. Command ended
up looking like:-
>PASSPHRASE="" duplicity --encrypt-key=A75B6459 --sign-key=44B9EBEA
incremental a file://b

Upon decrypting the files in b, GPG asked for the encryption key's
passphrase, despite the fact that duplicity never had access to it
(gpg-agent wasn't up, signing & encryption keys had different
passphrases). This is what my `gpg2 -k` looked like:-
>pub   1024R/44B9EBEA 2014-12-08 [expires: 2014-12-09]
>uid       [ultimate] Duplicity Sign <address@hidden>
>sub   1024R/90AB7AF8 2014-12-08 [expires: 2014-12-09]

>pub   1024R/A75B6459 2014-12-08 [expires: 2014-12-09]
>uid       [ultimate] Duplicity Encrypt <address@hidden>
>sub   1024R/73925D21 2014-12-08 [expires: 2014-12-09]

The subkeys only had their respective properties (90AB7AF8 = sign,
73925D21 = encrypt), and the master key only had the 'certify' property.
I also attempted it with a public key of someone I know (But, don't have
access to their private key), and it worked fine (Although, obviously
couldn't verify it did so because I'm not that person, and asking them
"Hey... can you decrypt this file sent to you?" sounds a little dodgy.

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk