distorted.org.uk KEY MANAGEMENT The various files are organized into subdirectories as follows. infra/ Infrastructure keys used to keep this system going. recov/ File extensions used are as follows. .pub Seccure public key. (See description of Seccure data formats below.) .recov Seccure ciphertext of key recov.pub `seccure' public key for recovery krb5-master Kerberos master password bkp-LABEL LUKS keyfile for backup volume LABEL disk-HOST LUKS keyfile for HOST's disk keys/ |- keeper/ | '- KEEPER/ | |- meta | '- I.pub |- key/ | '- ??? '- recov/ '- RECOV/ |- keepers |- current@ '- I/ |- pub |- KEEPER.param |- KEEPER.I.share '- SECRET.recov * Reference ** Asymmetric cryptography I've used B. Poettering's Seccure package for my asymmetric cryptography. It's been in Debian for a fair while and seems sane. If you're interested in what it does, I wrote my own implementation in Python. It seems pretty sensible, actually. It uses ECIES with AES in counter mode, and SHA256-HMAC for asymmetric encryption, and a variant of ECDSA with SHA512 for signatures. Seccure wants to read a single line of stuff as a passphrase. I use this rune to generate a public key. dd if=/dev/random of=master bs=1 count=512 | openssl sha384 -binary >priv To derive the public key, I say this: openssl base64 -in priv | seccure-key -q -F/dev/stdin -cp256 >pub For encryption, I use a 128-bit MAC. For decryption, you need this rune. openssl base64 -in priv | seccure-decrypt -q -F/dev/stdin -m128 ciphertext ** Secret sharing I've written my own tool for doing Shamir secret sharing. The underlying machinery is compatible with Daniel Silverstone's `gfshare' program and my Catacomb library's secret sharing. My `shamir' program has a number of important differences: * it produces output as plain text files which can be transported easily and so on; * it includes metadata, such as the number of shares, the threshold, and a hash of the final secret, along with the share data; * it stores the share index with the share data too, rather than encoding it in the file name where it's likely to be lost; and * it doesn't choose random share indices when issuing shares, because that's pointless. The `shamir issue' command writes one line for each share that it produces. I use this rune to split them into separate files. shamir issue 3/5 master | sed 's/^.*;i=\([^;]*\);/\1 &/' | while read i share; do echo $share >master.$i done You can recover the original secret by feeding shares, one per line, into `shamir recover'. All of the parameters are in the share data, so you don't need to know any of them. (I used the defaults anyway, since I carefully chose them to match what I wanted.) A share line has the following format: shamir-share:KEY=VALUE;KEY=VALUE;... where the following keys are defined (they must appear in this order): * n = total number of shares issued; * t = threshold (i.e., number of shares needed for recovery); * f = hash function name (an OpenSSL name, e.g., `sha256'); * h = base-64 encoded hash of the secret (using hash function `f'); * i = index of this share (starting from 0); and * y = base-64 share data. You can turn such a file of such lines into files suitable for `gfcombine' like this: sed 's/^.*;i=\(.*\);y=\(.*\)$/\1 \2/' | while read i sh; do ix=$(printf %03d $((i + 1))) echo $sh | openssl base64 -d >tmp/share.$ix done