Crypto lib

[Greg Hudson]

I like Sam's idea of omitting the prefix ("generic" or "common" or
whatever) if there's no good word for it, and Tom's idea of using
"builtin" to refer to the direct implementations.  So, my current layout
preference is for:

  lib/crypto/krb -- Kerberos-specific algorithms and API glue
  lib/crypto/builtin -- Direct back-end implementations
  lib/crypto/openssl -- Back-end implementations using OpenSSL
  lib/crypto/nss -- Back-end implementations using NSS
  lib/crpyto/bsafe -- Back-end implementations using BSafe
  etc.

(Back ends chosen for the sake of example; not trying to say which
back-end implementations we should do.)

It occurs to me that we don't have to descend into every directory in
every build; lib/crypto/Makefile.in can descend into krb, builtin, and
at most one of the backend-specific directories.  builtin/Makefile.in
would need all the complexity of knowing what direct implementations to
build based on which back end is in use, but openssl/Makefile.in and
nss/Makefile.in and bsafe/Makefile.in could just build everything, under
the assumption that the directory will only be used if that back end was
selected at configure time.

On Thu, 2009-06-11 at 10:34 -0400, Tom Yu wrote:
> I think it would be best to use some name including "builtin" for
> direct implementations of crypto primitives such as block ciphers,
> hash functions, etc.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev