1 distorted.org.uk KEY MANAGEMENT
3 The various files are organized into subdirectories as follows.
5 infra/ Infrastructure keys used to keep this system going.
8 File extensions used are as follows.
10 .pub Seccure public key. (See description of Seccure data
13 .recov Seccure ciphertext of key
17 recov.pub `seccure' public key for recovery
19 krb5-master Kerberos master password
20 bkp-LABEL LUKS keyfile for backup volume LABEL
21 disk-HOST LUKS keyfile for HOST's disk
43 ** Asymmetric cryptography
45 I've used B. Poettering's Seccure package for my asymmetric
46 cryptography. It's been in Debian for a fair while and seems sane. If
47 you're interested in what it does, I wrote my own implementation in
48 Python. It seems pretty sensible, actually. It uses ECIES with AES
49 in counter mode, and SHA256-HMAC for asymmetric encryption, and a
50 variant of ECDSA with SHA512 for signatures.
52 Seccure wants to read a single line of stuff as a passphrase. I use
53 this rune to generate a public key.
55 dd if=/dev/random of=master bs=1 count=512 |
56 openssl sha384 -binary >priv
58 To derive the public key, I say this:
60 openssl base64 -in priv | seccure-key -q -F/dev/stdin -cp256 >pub
62 For encryption, I use a 128-bit MAC. For decryption, you need this rune.
64 openssl base64 -in priv |
65 seccure-decrypt -q -F/dev/stdin -m128 ciphertext
69 I've written my own tool for doing Shamir secret sharing. The
70 underlying machinery is compatible with Daniel Silverstone's `gfshare'
71 program and my Catacomb library's secret sharing. My `shamir' program
72 has a number of important differences:
74 * it produces output as plain text files which can be transported
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;
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
83 * it doesn't choose random share indices when issuing shares,
84 because that's pointless.
86 The `shamir issue' command writes one line for each share that it
87 produces. I use this rune to split them into separate files.
89 shamir issue 3/5 master |
90 sed 's/^.*;i=\([^;]*\);/\1 &/' |
91 while read i share; do
92 echo $share >master.$i
95 You can recover the original secret by feeding shares, one per line,
96 into `shamir recover'. All of the parameters are in the share data,
97 so you don't need to know any of them. (I used the defaults anyway,
98 since I carefully chose them to match what I wanted.)
100 A share line has the following format:
102 shamir-share:KEY=VALUE;KEY=VALUE;...
104 where the following keys are defined (they must appear in this order):
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.
113 You can turn such a file of such lines into files suitable for
114 `gfcombine' like this:
116 sed 's/^.*;i=\(.*\);y=\(.*\)$/\1 \2/' |
118 ix=$(printf %03d $((i + 1)))
119 echo $sh | openssl base64 -d >tmp/share.$ix