Project review: encryption performance

[Nicolas Williams]

On Tue, Jul 21, 2009 at 02:09:42PM -0400, ghudson at mit.edu wrote:
> Please review:
> http://k5wiki.kerberos.org/wiki/Projects/Encryption_Performance
> 
> The review end date is August 3, 2009, which is two weeks from now.
> However, implementation work will probably not begin until the
> implementation of
> http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity is
> complete.
> 
> This project proposal covers the extension of keyblocks to contain
> additional information when necessary (via a new opaque type named
> krb5_key) and the use of this ability to cache derived keys for
> improved performance.

 - How will this work:

   "The existing krb5_c versions of the new functions will be
   reimplemented in terms of the krb5_k functions, using an internal
   non-copying keyblock-to-key_st converter."

   ?

   Presumably the crypto plug-in has to be invoked to initialize the
   internal krb5_key.  Can that be generic enough that a "non-copying
   keyblock-to-key_st converter" is feasible?  And why does it matter
   that it be "non-copying"?  Do you expect a key copy operation to be
   slow?  (Key, not key schedule...)

   Which brings me to:

 - The SPI has to be public too, to some degree anyways.  E.g., the
   Solaris Kerberos team might want to wrap Solaris' PKCS#11-based krb5
   crypto into a plug-in for this interface; it'd be good to be able to
   review this project with an eye to ensuring third-party plug-ins are
   feasible.

   Can you include a definition of that SPI in the project page?

 - krb5_k_create_key() should probably know whether the given key can be
   further derived (i.e., if it is a protocol key).

 - For implementation of keyblock-based functions you might want the
   initializer to take a flag saying "don't bother caching derived keys,
   key schedules, or anything else" (since that might mean allocating
   memory you'll free right away).

 - You might want to mention PKCS#11 as a possible crypto provider, not
   just OpenSSL and NSS.

Nico
--