blob: 40ec8239a7cf24d736257c80a032ccf41cce9186 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
Keyringer
=========
Encrypting a key
----------------
scripts/encrypt <file>
Decrypting a key (only to stdout)
---------------------------------
scripts/decrypt <file>
Re-encrypting a key
-------------------
scripts/recrypt <file>
Notes
-----
1. The <file> is any file inside the keys/ folder.
2. Never decrypt a key and write it to the disk, except
if you're adding it to your personall keyring.
3. Recipients are defined at file config/recipients.
Please add just trustable recipients.
Using with GNU Privacy Guard
----------------------------
Exporting public keys:
gpg --armor --export <keyid>
Exporting private keys (take care):
gpg --armor --export-secret-keys
Concepts
--------
Basic idea is:
- Encrypt stuff with ppl's gpg pubkeys and push the output
in a git repo.
- Let ppl keep it in sync with the repo and the keys are
shared :)
For "key" it's meant anything as the script work with stdin and output things to
files, so it can be passphrases, private keys or other kind of info.
It's possible to share keys using an encrypted mailing list, but the main
difficulty is to track the message where the keys are.
With theses scripts, the workflow is more or less like this:
- You have a git repo for secret keys.
- You run the "encrypt" command and paste your private key to this
command (so no plaintext disk write).
- The encrypt command writes an encrypted file to the repo.
- You manually add it to git and push it to remote repositories.
- Optionally, other ppl pulls the changes but they dont need to
decrypt anything until they need to use the keys.
So it's just gpg-encrypted data atop of a git repository (one can think of a
kind of distributed encrypted filesystem).
Git was chosen to host encrypted info mostly for two reasos: easy to distribute
and its the only VCS known to make easier repository history manipulation.
One possible drawback: the repo has pubkey information attached, which can be
linked to real ppl (and then disclose the information about who has access to a
given key), but it's possible to:
- Keep the repo just atop of an encrypted and non-public place.
- Or to consider an integration with gpg's --hidden-recipient option.
TODO
----
Currently the script just handle encrypt/decrypt of files but no automatic git
operation (which needs to be managed by hand). There are lots of things that
can be enhanced:
- Enhanced documentation.
- Better intregation with gpg.
- Smarter scripts, support for "groups" of users in a way an user
can encrypt a given key just to some users.
- Interface with ssss where the scripts automatically splits passphrases
into ssss tokens and encrypt those to different groups of users.
- Security checks.
- Hidden recipient support.
- Git automation, including:
- Automatic repository maintenance functions.
- Hooks to inform users.
- Removal of old history.
Development
-----------
Currently there are have no solid plans to package these scripts but it might
be possible instead to integrate the scripts and the keys using git's submodule
feature.
|
