Difference between revisions of "Projects/Crypto modularity"

Latest revision as of 23:12, 15 February 2010

Desired Changes

The objective of this project is to clear the way for the cryptographic implementations from various providers to be used in lieu of MIT Kerberos custom cryptography. The existing crypto directory should be divided into two subdirectories krb and builtin. The first of these folders will be designated for the Kerberos specific functionality, while the second directory will be a place-holder for the generic lower level cryptographic primitives. Additional directories will be added as part of the adaptation of vendor's crypto-systems (such as NSS, OpenSSL, BSAFE, PKCS#11, etc,)

Functional Requirements

The existing crypto and hash providers will serve as a cryptographic front-end, while the back-end will provide the implementation dependent cryptographic primitives. The crypto provider should be chosen with a designated flag during configure process.

Design

• Divide crypto directory into two subdirectories:

krb - Kerberos specific functionality. Provides front-end into crypto routines. Files: checksum, dk, aead, keyhash_provider, nfold, key ops, etype ops, prf, raw, crc32, old , prng, yarrow builtin - MIT implementations. Provides back-end of the crypto routines. Files: md*, des*, aes, hmac, sha1, enc_provider, hash_provider, pbkdf2

• Add a new directory to provide a crypto implementation based on OpenSSL or NSS crypto-system. The directory will have the structure similar to builtin.

For example, the modifications in md5 subdirectory may look like the following if OpenSSL implementation is used:

 rsa-md5.h:
 #include <openssl/evp.h>
 #include <openssl/md5.h>
 ...
 /* Data structure for MD5 (Message-Digest) computation */
 typedef struct {
    EVP_MD_CTX ossl_md5_ctx;     /* OPEN_SSL */
    krb5_ui_4 i[2];                       /* number of _bits_ handled mod 2^64 */
    krb5_ui_4 buf[4];                     /* scratch buffer */
    unsigned char in[64];                 /* input buffer */
    unsigned char digest[16];             /* actual digest after MD5Final call */
 } krb5_MD5_CTX;
 ...
 md5.c:
 void krb5_MD5Init (krb5_MD5_CTX *mdContext)
 {
    EVP_MD_CTX_init(&mdContext->ossl_md5_ctx );
    EVP_DigestInit_ex(&mdContext->ossl_md5_ctx , EVP_md5(), NULL);
 }
 void krb5_MD5Update (krb5_MD5_CTX *mdContext, const unsigned char *inBuf, unsigned int inLen)
 {
    EVP_DigestUpdate(&mdContext->ossl_md5_ctx , inBuf, inLen);
 }
 void krb5_MD5Final (krb5_MD5_CTX *mdContext)
 {
   EVP_DigestFinal_ex(&mdContext->ossl_md5_ctx , mdContext->digest , NULL);
 }

• Add new flags to configure --with-crypto-impl to control the use of the desired cryptographic implementation. The lib/crypto make system will be modified to build lib/crypto/krb and lib/crypto/builtin files to construct libk5crypto library in case when builtin cryptography is desired. However, in the cases when the different crypto implementation was chosen, builtin makesystem will direct the build process into the implementation specific directory.

Tasks/ Milestones

1. Split crypto directory into two directories krb and builtin;
2. Makefile changes to handle the new structure of lib/crypto directory;
3. Implement back-end crypto based on OpenSSL or NSS;
4. Develop test cases;

Testing Plan

1. Use "make check" to ensure krb5 integrity;
2. Use existing and new client/server test tools built with mixed crypto implementations.

Review

This section documents the review of the project according to Project policy. It is divided into multiple sections. First, approvals should be listed. To list an approval type

#~~~~

on its own line. The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with {{project-block}}.

Approvals

Greg Hudson, 2009-07-15

Discussion