idea
This commit is contained in:
parent
79031223fd
commit
0be6cad7a8
1 changed files with 59 additions and 0 deletions
59
doc/todo/encrypted_keys_in_git_repository.mdwn
Normal file
59
doc/todo/encrypted_keys_in_git_repository.mdwn
Normal file
|
@ -0,0 +1,59 @@
|
|||
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]]
|
Loading…
Add table
Add a link
Reference in a new issue