Subject: cgdconfig changes
To: None <current-users@NetBSD.ORG, tech-security@NetBSD.ORG>
From: Roland Dowdeswell <elric@imrryr.org>
List: current-users
Date: 03/23/2003 21:31:33
I have just made significant changes to cgdconfig.  These changes
should be reflected in the man page and I shall provide a summary
here.

I've added a number of new features, including the -G flag, an ffs
verify_method, allowing multiple keygen stanzas which are xor'ed
together to produce the key and calibrating the iteration count of
PKCS#5 PBKDF2 to the current machine's speed.

NEW PARAMSFILE PARSER

	I have have also modified the paramsfile grammar.  It is
	mostly backwards compatible.  There are statements that
	were not generated by cgdconfig(8) or likely to be entered
	by humans that the old parser would accept but the new
	parser will not, such as:

		algorithm a e s - c b c

	but I think that this will not be much of an issue in
	practice.

	I have been thinking about deprecating the old syntax
	entirely at some point, probably before 2.0 is release,
	but I haven't come up with a decision about that.

THE -G FLAG

	With the -G flag, one can generate a new parameters file
	which will produce the same key as an existing parameters
	file.

	So, if:

		# cgdconfig cgd0 /dev/wd0e params
		/dev/wd0e's passphrase: foobar

	configures your disk, then you can

		# cgdconfig -G params > params2
		old's passphrase: foobar
		new's passphrase: f00b4r

	to create a new parameters file `params2'.  Now either the
	original cgdconfig command or the new command:

		# cgdconfig cgd0 /dev/wd0e params2
		/dev/wd0e's passphrase: f00b4r

	will correctly configure your cgd(4).

	You can do some interesting things with this functionality,
	such as create storedkey paramsfiles on other computers
	for disaster recovery, create paramsfiles that use different
	key generation methods for different environments or allow
	different people to access the same disk using different
	passphrases.

KEYGEN'S ARE STANZAS

	Well, I made the keygen statements into stanzas to allow
	one to specify more than one of them.  In the case that
	more than one is specified they are just xor'ed together
	to produce the final key.  This allows basic n-factor
	authentication behaviour.  The only real n-factor auth that
	we currently support is passphrase/storedkey.  The storedkey
	could be, say, stored on a USB dongle and hence would
	qualify as ``something you have'' to go along with the
	passphrase ``something you know''.

	I'm planning on adding another keygen method at some point
	to make this a little more interesting.

PKCS#5 PBKDF2 ITERATION CALIBRATION

	I cannot stress enough how important having a reasonably
	large iteration count is for PKCS#5 PBKDF2.  People generally
	choose passphrases that are relatively low in entropy and
	thus the passphrase is by far the weakest link for most
	forms of encryption.  The only answer to this problem is
	to increase the challenge of performing a dictionary attack
	on the passphrase.  PKCS#5 PBKDF2 is designed to make this
	more difficult and includes an iteration count to make
	things take a little longer.  What I do in this update is
	calibrate the PKCS#5 PBKDF2 algorithm to take about 1s to
	generate the key from the passphrase on your computer.  1s
	is not very long to wait when configuring the disk, but it
	is an eternity if you are trying to perform a dictionary
	attack.  I used calibration because (1) I couldn't think
	of a good iteration count for both VAX and Alpha, and (2)
	I didn't want to have to keep bumping the iteration count
	every year.

DISCLAIMER

	This was a pretty major roto-till, so I expect that I
	introduced a number of bugs.  Please use the send-pr
	mechanism to report them and I shall fix them as soon as
	I can.

Thanks,

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/