chiark / gitweb /
cryptop.public: Don't check an ACL.
[distorted-keys] / README
... / ...
CommitLineData
1distorted.org.uk KEY MANAGEMENT
2
3The various files are organized into subdirectories as follows.
4
5infra/ Infrastructure keys used to keep this system going.
6recov/
7
8File extensions used are as follows.
9
10.pub Seccure public key. (See description of Seccure data
11 formats below.)
12
13.recov Seccure ciphertext of key
14
15
16
17recov.pub `seccure' public key for recovery
18
19krb5-master Kerberos master password
20bkp-LABEL LUKS keyfile for backup volume LABEL
21disk-HOST LUKS keyfile for HOST's disk
22
23keys/
24|- keeper/
25| '- KEEPER/
26| |- meta
27| '- I.pub
28|- key/
29| '- ???
30'- recov/
31 '- RECOV/
32 |- keepers
33 |- current@
34 '- I/
35 |- pub
36 |- KEEPER.param
37 |- KEEPER.I.share
38 '- SECRET.recov
39
40
41* Reference
42
43** Asymmetric cryptography
44
45I've used B. Poettering's Seccure package for my asymmetric
46cryptography. It's been in Debian for a fair while and seems sane. If
47you're interested in what it does, I wrote my own implementation in
48Python. It seems pretty sensible, actually. It uses ECIES with AES
49in counter mode, and SHA256-HMAC for asymmetric encryption, and a
50variant of ECDSA with SHA512 for signatures.
51
52Seccure wants to read a single line of stuff as a passphrase. I use
53this rune to generate a public key.
54
55 dd if=/dev/random of=master bs=1 count=512 |
56 openssl sha384 -binary >priv
57
58To derive the public key, I say this:
59
60 openssl base64 -in priv | seccure-key -q -F/dev/stdin -cp256 >pub
61
62For encryption, I use a 128-bit MAC. For decryption, you need this rune.
63
64 openssl base64 -in priv |
65 seccure-decrypt -q -F/dev/stdin -m128 ciphertext
66
67** Secret sharing
68
69I've written my own tool for doing Shamir secret sharing. The
70underlying machinery is compatible with Daniel Silverstone's `gfshare'
71program and my Catacomb library's secret sharing. My `shamir' program
72has a number of important differences:
73
74 * it produces output as plain text files which can be transported
75 easily and so on;
76
77 * it includes metadata, such as the number of shares, the threshold,
78 and a hash of the final secret, along with the share data;
79
80 * it stores the share index with the share data too, rather than
81 encoding it in the file name where it's likely to be lost; and
82
83 * it doesn't choose random share indices when issuing shares,
84 because that's pointless.
85
86The `shamir issue' command writes one line for each share that it
87produces. I use this rune to split them into separate files.
88
89 shamir issue 3/5 master |
90 sed 's/^.*;i=\([^;]*\);/\1 &/' |
91 while read i share; do
92 echo $share >master.$i
93 done
94
95You can recover the original secret by feeding shares, one per line,
96into `shamir recover'. All of the parameters are in the share data,
97so you don't need to know any of them. (I used the defaults anyway,
98since I carefully chose them to match what I wanted.)
99
100A share line has the following format:
101
102 shamir-share:KEY=VALUE;KEY=VALUE;...
103
104where the following keys are defined (they must appear in this order):
105
106 * n = total number of shares issued;
107 * t = threshold (i.e., number of shares needed for recovery);
108 * f = hash function name (an OpenSSL name, e.g., `sha256');
109 * h = base-64 encoded hash of the secret (using hash function `f');
110 * i = index of this share (starting from 0); and
111 * y = base-64 share data.
112
113You can turn such a file of such lines into files suitable for
114`gfcombine' like this:
115
116 sed 's/^.*;i=\(.*\);y=\(.*\)$/\1 \2/' |
117 while read i sh; do
118 ix=$(printf %03d $((i + 1)))
119 echo $sh | openssl base64 -d >tmp/share.$ix
120 done