[OpenAFS-devel] configurable cryptosystem support

[Marcus Watts]

I'm in the process of adding "configurable crypto support" to k5ssl,
part of rxk5 for openafs.  I have the configuration logic working with
all the features listed below, I just have to merge it in with other
changes also in the queue (such as windows support, verifykt, etc...)

At build time, configure -help will advertise this option (among others):

	  --enable-k5ssl-crypto                {,no,only}{des,des3,rc4,aes}

in fact, the list of available crypto systems is somewhat
larger than this:
	des	- des (several variants)
	des3	- des3
	rc4	- rc4
	rc4exp	- rc4 + rc4exp (both)
	aes	- aes128+aes256
	cast	- (old experiment) cast
	rc6	- (old experiment) rc6
optionally with these prefixes,
	onlyXXX	- turn off all other cryptosystems before enabling this one
	noXXX	- turn this cryptosystem off
also
	all	- all available cryptosystems
	default	- default list of crypto (des,des3,rc4,aes)

So, some possible combinations:
	cast		- default cryptosystems + cast
	all;nodes	- all cryptosystems but des
	onlydes,des3	- des+des3
	aes,rc4exp	- default (aes is already part of that) + rc4+rc4exp.
(seperator here is one or more of any character but 0-9a-z.)

There's no reason anybody would want to build cast or rc6 except
for experimental purposes.  That's why they're not advertised.

rc4exp is a degraded version of rc4 has an effective key space of 40 bits,
done by microsoft for export purposes.  I don't know if microsoft still
does this, but I believe neither heimdal nor mit support this anymore.
There's certainly no reason to advertise or use this
with openafs.

Turning off a cryptosystem does not just remove it from the
table of available cryptosystems.  It will actually eliminate all
the object files and code from the list built for the kernel & (if
built) userland, making the resulting binaries and libraries smaller
and providing an absolute and verifiable guarantee that
it's not available to k5ssl.

It's been proposed to ship openafs "strong crypto" intentionally
without des compatibility.  I have some local reasons to care about
des, hence the reason why this is configurable.

k5ssl provides basic cryptographic support for rxk5 inside the kernel.
k5ssl can also provide k5 support for afs userland code if
for some reason the userland environment does not have a suitable
kerberos library.  If rxk5 is built using a regular externally provided
kerberos library, the cryptosystems supported are determined solely
by that kerberos library.  In any current public distribution of
kerberos, that includes des.  Presumably future distributions of kerberos
will start to include configurable cryptosystem support at build time
in at least some form.

Userland k5ssl can link with openssl and take advantage of any
assembler code or hardware accelleration that might provide.
Of course you can also link against heimdal+openssl & get the
same advantages.

Kernel-land k5ssl uses its own optimized portable C crypto code
(including its very own copy of des).  In the future it
might support either assembler versions of some crypto code,
or it might support interfacing to the local systems's native
crypto interface if that has suitable hardware accelleration.
I don't think these are worth worrying about until rxk5 is actually
working well on lots of different hardware platforms first.

				-Marcus Watts