close with comment

This commit is contained in:
Joey Hess 2015-03-31 15:46:00 -04:00
parent 42bbed7ce5
commit 1f113e852b
2 changed files with 25 additions and 0 deletions

View file

@ -2,3 +2,5 @@
It is not possible to put encrypted content in place on remotes with just a public GPG key. You always need the private key, even for encryption. I guess this is because how the cipher HMAC is used for replacing file names with their hashes. However, if that requirement (having secret file names) was dropped, I assume a pubkey-only mode could be implemented?
My specific use case is backup archiving. I have my backups packed in archive files and want to use git-annex to copy the archives to offsite remotes (S3). In that case, I don't care much about hiding file names, but would appreciate the increased security of not having the secret key on the backup server. It would only be needed if I wanted to verify or restore backups.
> [[closed|done]] per my comment --[[Joey]]

View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2015-03-31T19:37:20Z"
content="""
When you use encryption=pubkey, the symmetric key that is used for
HMAC encryption of filenames is encrypted using your gpg private key.
The contents of files are also encrypted using your gpg private key
(not using the symmetric key; that mode is encryption=hybrid).
So, with encryption=pubkey, all that can be done with that symmetric key is
to HMAC encrypt filenames and try to find results that match the HMACed
filenames used on the remote. So, if you don't care about filenames
leaking, you could publish that symmetric key with no bad effects. Its
security is not important to you based on what you've said.
But again, that symmetric key is encrypted with your gpg private key.
The only way to decrypt it would be to break your gpg key somehow. In which
case you have big problems. But not ones caused by the existence of the
symmetric key.
So, I see no benefit to the suggested mode.
"""]]