Crypto Modularity proj proposal

Nicolas Williams Nicolas.Williams at
Wed Jun 24 13:50:43 EDT 2009

On Wed, Jun 24, 2009 at 01:40:40PM -0400, Greg Hudson wrote:
> The code organization part has already been discussed and I think is
> mostly uncontroversial.
> The hard part is what we do to allow keyblocks to support:
>   * Caching of derived keys

I think it turns out to be easier than we (Wyllys and I) thought years
ago when Wyllys implemented this for Solaris.  Love argues that there's
no need to change krb5_keyblock, mostly because performance matters most
in the GSS-API mechanism, where we have a great place to stash derived
keys: the mech-specific gss_ctx_id_t.  I agree with that.

If you do this then only GSS apps will get the perf improvement, though
you could also cache derived keys in krb5_auth_context for raw krb5

>   * Caching of implementation object handles for keys
>   * References to keys stored opaquely in cryptographic modules
> The second and third points are related; I'm just drawing a distinction
> between the performance goal of not having to create an object handle
> for each operation and the functionality goal of being able to support
> opaque, external storage of long-term keys.

Keys stored in HW tokens should be allowed only for long-term keys.  If
you do that then you need only make the token/slot/session available to
the pre-auth plugins (and on the KDC side for using the master DB keys
and, maybe, TGS and kadmin keys).  Again, no need to touch


More information about the krbdev mailing list