Project review: encryption performance
Nicolas.Williams at sun.com
Tue Jul 21 14:41:13 EDT 2009
On Tue, Jul 21, 2009 at 02:09:42PM -0400, ghudson at mit.edu 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
> http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity is
> 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