CVS log for src/sbin/cgdconfig/Makefile

Up to [cvs.NetBSD.org] / src / sbin / cgdconfig

Request diff between arbitrary revisions

Keyword substitution: kv
Default branch: MAIN

Pull up following revision(s) (requested by riastradh in ticket #941):

	sbin/cgdconfig/params.c: revision 1.35
	sbin/cgdconfig/params.h: revision 1.15
	sbin/cgdconfig/cgdconfig.c: revision 1.62
	sbin/cgdconfig/cgdconfig.c: revision 1.63
	sbin/cgdconfig/cgdconfig.8: revision 1.58
	sbin/cgdconfig/cgdconfig.8: revision 1.59
	sbin/cgdconfig/Makefile: revision 1.23

cgdconfig(8): KNF in cgdconfig.c.
No functional change intended.

PR/58212: Malte Dehling: Add zfs verification method

cgdconfig(8): Estimate verify methods' false accept probabilities.
An addendum following discussion around:
PR bin/58212: cgdconfig(8): Add zfs verification method

PR/58212: Malte Dehling: Add zfs verification method

cgdconfig(8): Add support for shared keys.

New clause `shared <id> algorithm <alg> subkey <info>' in a keygen
block enables `cgdconfig -C' to reuse a key between different params
files, so you can, e.g., use a single password for multiple disks.
This is better than simply caching the password itself because:

- Hashing the password is expensive, so it should only be done once.

  Suppose your budget is time t before you get bored, and you
  calibrate password hash parameters to unlock n disks before you get
  bored waiting for `cgdconfig -C'.

  . With n password hashings the adversary's cost goes up only by a
    factor of t/n.
  . With one password hashing and n subkeys the adversary's cost goes
    up by a factor of n.

  And if you ever add a disk, rehashing it will make `cgdconfig -C'
  go over budget, whereas another subkey adds negligible cost to you.

- Subkeys work for other types of keygen blocks, like shell_cmd,
  which could be used to get a key from a hardware token that needs a
  button press.

The <info> parameter must be different for each params file;
everything else in the keygen block must be the same.  With this
clause, the keygen block determines a shared key used only to derive
keys; the actual key used by cgdconfig is derived from the shared key
by the specified algorithm.

The only supported algorithm is hkdf-hmac-sha256, which uses
HKDF-Expand of RFC 5869 instantiated with SHA-256.

Example:

	algorithm aes-cbc;
	iv-method encblkno1;
	keylength 128;
	verify_method none;
	keygen pkcs5_pbkdf2/sha1 {
		iterations 39361;
		salt AAAAgMoHiYonye6KogdYJAobCHE=;
		shared "pw" algorithm hkdf-hmac-sha256
		    subkey AAAAgFlw0BMQ5gY+haYkZ6JC+yY=;
	};

The key used for this disk will be derived by

	HKDF-HMAC-SHA256_k(WXDQExDmBj6FpiRnokL7Jg==),

where k is the outcome of PBKDF2-SHA1 with the given parameters.

Note that <info> encodes a four-byte prefix giving the big-endian
length in bits of the info argument to HKDF, just like all other bit
strings in cgdconfig parameters files.

If you have multiple disks configured using the same keygen block
except for the info parameter, `cgdconfig -C' will only prompt once
for your passphrase, generate a shared key k with PBKDF2 as usual,
and then reuse it for each of the disks.

Use the Makefile.inc from libargon2 (fixes the vax build that requires
a compiler hack).

make things behave just like before the libcrypt symbol renaming:
The normal cgdconfig binary is built with threads and the crunched one
in rescue without.

Re-enable threads; apparently we get different results depending if we are
threaded or not... This tastes like a bug.

Build argon2 inline so that crunched programs work. I also disabled threads
for now; we can put them back if needed.

-lpthread to LDADD (fixes lint build)

cgdconfig(8): Add an argon2id password-based key generation method

This provides an extra level of side-channel and cracking resistance
compared to the pre-existing pkcs5_pbkdf2/sha1 method used for
password-based disk encryption.

Several new keygen parameters are supported:

	memory (integer, in kilobytes)
	parallelism (integer, usually the number of CPU cores)
	version (integer, usually 19...)

We do our best to calibrate these automatically when the paramsfile
is initially generated.

lgtm riastradh@

replace openssl HMAC(3) with our hmac(3).

Convert from the oldstyle cgd_kops.op_open to the newstyle prog_open
and define RUMPPRG.  Get rid of the Makefile.inc stuff, since it was
useful only for the oldstyle regime.

Use RUMP_ACTION to avoid having to specify the same information
in the Makefiles of all the consumers.

* allow specification of kernel operations vector
* make it possible to build cgdconfig as a library

Sync with HEAD.

Third (and last) commit. See http://mail-index.netbsd.org/source-changes/2009/05/13/msg221222.html

define YY_NO_INPUT where appropriate, from Kurt J. Lidl per PR misc/41160

Sync with HEAD.

Sync with wrstuden-revivesa-base-2.

Adjust this to not need -Wno-pointer-sign.

Add HAVE_PCC tests for -Wno-pointer-sign.

sync with HEAD

Sync with HEAD.

Change incorrect usage of CFLAGS to CPPFLAGS

sprinkle some -fno-strict-aliasing and -Wno-pointer-sign with GCC4.

We link against libl and liby, so depend on them too.

Add -lcrypt where -lcrypto is specified.

We need -I., too.

-I. -> -I${.CURDIR}

substantial rototill of the code.

	o  added new features:
		o  -G:  generate a new paramsfile that produces the same
			key as the old paramsfile,
		o  ffs verify_method,
		o  multiple keygen methods that are xor'ed together
		   (for n-factor authentication), and
		o  calibrating the iteration count of PKCS#5 PBKDF2 to
		   the current machine's speed.
	o  changed paramsfile format to allow for the new features.
	o  replaced open-coded parser with yacc grammar.
	o  lots of supporting changes.
	o  updated documentation to reflect new features and new
	   paramsfile format.

Initial checkin of cgdconfig(8), a program to configure a cgd.