logo_kerberos.gif

Difference between revisions of "Projects/Crypto modularity"

From K5Wiki
Jump to: navigation, search
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{project-early}}
+
{{project-rel|1.8}}
   
 
== Desired Changes ==
 
== 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 etc)
+
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 ==
 
== Functional Requirements ==
Line 14: Line 14:
   
 
krb - Kerberos specific functionality. Provides front-end into crypto routines.
 
krb - Kerberos specific functionality. Provides front-end into crypto routines.
Files: checksum, dk, aead, enc_provider, hash_provider, keyhash_provider, nfold, key ops, etype ops, prf, raw, crc32, old [, prng, yarrow]
+
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.
 
builtin - MIT implementations. Provides back-end of the crypto routines.
Files: md*, des*, aes, hmac, sha1, pbkdf2 [, prng, yarrow]
+
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.
 
* 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.
Line 49: Line 49:
 
}
 
}
   
In addition, if back-end refers to keys using opaque handles, as might be needed on a PKCS#11 device, “overload” krb5_keyblock structure by using its member “krb5_octet *contents” as a void ptr to the opaque key handle/structure. To ensure that the existing applications would still work one of the options is to assign a special value to magic that would control how krb5_keyblock->contents is used.
 
 
* 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.
 
* Add new flags to configure 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 ==
 
== Tasks/ Milestones ==
Line 64: Line 62:
 
# Use "make check" to ensure krb5 integrity;
 
# Use "make check" to ensure krb5 integrity;
 
# Use existing and new client/server test tools built with mixed crypto implementations.
 
# 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
  +
:<nowiki>#~~~~</nowiki>
  +
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 <nowiki>{{project-block}}</nowiki>.
  +
  +
===Approvals===
  +
  +
Greg Hudson, 2009-07-15
  +
  +
===Discussion===

Latest revision as of 00:12, 16 February 2010

This project was completed in release 1.8.


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