git-annex/doc/todo/encrypted_keys_in_git_repository.mdwn

The idea is to have a type of key that is based on a hash of the annexed
file, but with some form of encryption or password protection. 

So someone who can access the git repository is prevented from checking
known hashes of files, and learning about content in the repository that is
not available to them. (However, they would be able to see filenames
and commit metadata, which might also expose information about what the
files are. This is not a fully encrypted git repository like can be made
with gcrypt.)

This might be an added layer of security, or the git repository might be
made public, including perhaps some of the annexed files, while this is
used to obscure the hashes of some other annexed files. For example, a
scientific dataset might make public files that are derived from patient
data, and use this for the patient data files.

----

If two such repositories were merged, git-annex would need to somehow
be able to tell how to decrypt a key, which could have come from either
repository. So it seems that the key needs to include within it some
identifier of the secret that is used to encrypt it. For example:

    ENC--ident--foo

Where ident would be something like a UUID of the secret, and foo is the
file's hash (and perhaps size, or indeed a whole regular key) that is
encrypted by the secret.

----

Should the key's size be included only in encrypted form, or in plaintext?

Since git-annex constructs a Key without using the associated Backend,
it currently parses the size field the same way for each type of key.
So, it does not seem to be possible to encrypt the size field and 
use that encrypted size to populate keySize. What would be
doable though, is to replace uses of keySize with a new Backend method that
returns the size.

----

Should the encryption method be reversible?

If the encryption method is not reversible, the key's size would need to be
included in plaintext, or left out entirely.

But it does not seem necessary for the encryption method to be reversible
otherwise. Consider if scrypt was used. When adding a file, git-annex would
first hash it, and then run it through scrypt. That is not reversible,
so when fscking a file, just repeat the same process and compare the
resulting scrypt keys.

Not being reversible is a nice benefit, because it makes it much harder
for an attacker to brute-force. If it's reversible the attacker can
brute-force the user's password, looking for a password that decrypts
to something that looks right.

--[[Joey]]

> [[wontfix|done]]; see description --[[Joey]]