Project review: encryption performance

Nicolas Williams Nicolas.Williams at
Tue Jul 21 14:41:13 EDT 2009

On Tue, Jul 21, 2009 at 02:09:42PM -0400, ghudson at wrote:
> Please review:
> 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
> 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

   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.


More information about the krbdev mailing list