Added new encryption=sharedpubkey mode for special remotes.

This is useful for makking a special remote that anyone with a clone of the
repo and your public keys can upload files to, but only you can decrypt the
files stored in it.
This commit is contained in:
Joey Hess 2016-05-10 16:50:31 -04:00
parent 2d00523609
commit e219289c83
Failed to extract signature
7 changed files with 114 additions and 63 deletions

View file

@ -23,8 +23,9 @@ to disable encryption. To use encryption, you run
* `git annex initremote newremote type=... encryption=hybrid keyid=KEYID ...`
* `git annex initremote newremote type=... encryption=shared`
* `git annex initremote newremote type=... encryption=pubkey keyid=KEYID ...`
* `git annex initremote newremote type=... encryption=sharedpubkey keyid=KEYID ...``
## hybrid encryption keys
## hybrid encryption keys (encryption=hybrid)
The [[hybrid_key_design|design/encryption]] allows additional
encryption keys to be added on to a special remote later. Due to this
@ -53,7 +54,7 @@ probably to replace a revoked key:
See also [[encryption_design|design/encryption]] for other security
risks associated with encryption.
## shared encryption key
## shared encryption key (encryption=shared)
Alternatively, you can configure git-annex to use a shared cipher to
encrypt data stored in a remote. This shared cipher is stored,
@ -66,7 +67,7 @@ The advantage is you don't need to set up gpg keys. The disadvantage is
that this is **insecure** unless you trust every clone of the git
repository with access to the encrypted data stored in the special remote.
## regular public key encryption
## regular public key encryption (encryption=pubkey)
This alternative simply encrypts the files in the special remotes to one or
more public keys. It might be considered more secure due to its simplicity
@ -88,9 +89,25 @@ key has to be kept around to be able to decrypt those files.
that the key has been compromised, it is **insecure** to leave files
encrypted using that old key, and the user should re-encrypt everything.)
(Because filenames are MAC'ed, a cipher still needs to be
generated (and encrypted to the given key IDs). It is only used for MHAC
encryption of filenames.)
(A cipher still needs to be generated (and is encrypted to the given key IDs).
It is only used for HMAC encryption of filenames.)
## regular public key encryption with shared filename encryption (encryption=sharedpubkey)
This is a variation on encryption=pubkey which lets anyone who
has access to the gpg public keys store files in the special remote.
But, only owners of the corresponding private keys can retrieve the files
from the special remote.
git annex initremote newremote type=... [encryption=hybrid] keyid=KEYID ...
This might be useful if you want to let others drop off files for you in a
special remote, so that only you can access them.
The filenames used on the special remote are encrypted using HMAC,
which prevents the special remote from seeing the filenames. But, anyone
who can clone the git repository can access the HMAC cipher; it's stored
**unencrypted** in the git repository.
## MAC algorithm

View file

@ -12,3 +12,5 @@ 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.
> Added "encryption=sharedpubkey" [[done]] --[[Joey]]