Makefile.am: Move cryptop stuff after keys stuff.

[distorted-keys] / README

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