Crypto lib

[Greg Hudson]

A discussion of directory naming (a topic which I know is more
interesting to me than many other people):

The names "common-mit", "common-openssl", and "krb" came from me, and
I'm not fond of any of them; I've been trying to think of better ones.
A little more background on the distinction we're trying to draw:

libk5crypto contains three basic kinds of stuff:

  1. Generic, externally defined crypto algorithms like AES
  2. Kerberos-specific algorithms like CF2
  3. Kerberos-specific bookkeeping routines defining the API (enctypes
etc.)

The idea is to make category 1 pluggable at compile time, recognizing
that any particular back end (OpenSSL, NSS, BSafe, PKCS11) may only
provide a subset of the algorithms.  So "krb" is my dummy name to hold
the Kerberos-specific stuff (category 2 and 3) and "common-mit" and
"common-openssl" are my dummy names for the direct implementations of
(1) and the indirect implementations via OpenSSL.

I don't like the prefix "common" because it is often used to mean
"common across all architectures" (or across all something else), and
what it means here is something else.  I don't like the name
"common-mit" in particular because it suggests that MIT is the original
author of the code contained therein, which is not true in some (most?)
cases.  I don't like the name "krb" on principal (the name of the
project is usually meaningless as a subdirectory name within that
project) but it's the most reasonable.

After a few more minutes of thought, I tentatively like the names
"generic-direct", "generic-openssl", and "krb" better than the set of
names I initially picked.

The idea, incidentally, is for the build to descend into all
subdirectories, and inside each subdirectory to pick which objects to
build based on configure-time options.  For example, a build with the
OpenSSL back end would build all objects inside generic-openssl, and
some of the objects inside generic-direct corresponding to the
algorithms not implemented by OpenSSL.

(I'm aware that Sam thinks that NSS is a better initial back end than
OpenSSL.  I continued using OpenSSL in my discussion above for the sake
of example, but that doesn't mean I have any particular opinion on that
issue.)