Added a comment

1 files changed, 20 insertions, 0 deletions

diff --git a/doc/bugs/using_gpg_encryption_with_multiple_keys_fails/comment_3_3a6ff3dbc24850b065d045c7c9398eb1._comment b/doc/bugs/using_gpg_encryption_with_multiple_keys_fails/comment_3_3a6ff3dbc24850b065d045c7c9398eb1._comment
new file mode 100644
index 000000000..7dab63081
--- /dev/null
+++ b/doc/bugs/using_gpg_encryption_with_multiple_keys_fails/comment_3_3a6ff3dbc24850b065d045c7c9398eb1._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.2"
+ subject="comment 3"
+ date="2014-07-15T20:42:15Z"
+ content="""
+So let's think about whether gcrypt using gpg -R makes sense from the git-annex perspective.
+
+Without -R, an attacker who can look at the remote, encrypted git repository can easily see the gpg keys of participants. This could allow them to perform other, more targeted attacks to get at the unencrypted repository.
+
+If the user is using eg, github to store the gcrypt repo, an attacker can easily find out who owns the repo anyway, so they know who to attack then, even when -R is used. The -R can still prevent them from finding out when it's encrypted to additional users than the owner.
+
+As far as the assistant goes, it only ever sets up a gcrypt repo with one participant. Using either an existing gpg key of the user, or generating a new one (which doesn't even have their name on it). Adding more participants to a gcrypt repo is tricky, and the assistant doesn't currently support it. But I'd like to have it support setting up multiple participants eventually. So the current limitations of the assistant are not a sufficient reason to avoid using -R.
+
+So, it seems to come down to the question of whether it's a reasonable goal for git-annex, when used with gcrypt, to hide the identities of people who use a repository. And whether such a goal is worth the security/usability tradeoff of the user getting gpg passphrase prompts for other keys.
+
+Hmm, when git-annex encrypts files to send them to a special remote, if it's using encryption=pubkey, it does not use -R. So an attacker can get the list of participants that way. Although the more common approach is for git-annex to encrypt using encryption=shared/hybrid, which uses a symmetric cipher, which avoids that problem. There are plenty of other things that git-annex can do that would leak identity.
+
+It kind of seems to me that if you want to prevent anyone learning who uses your repository, you are going to need to be very cautious (using tor etc) and the  most git-annex can do is be open about how it works and avoid adding any obstacles. Looking at it this way, such a user, or group of users, would be well-served by using gpg keys that don't have their names on them...
+"""]]