Crypto Modularity proj proposal

[Nicolas Williams]

On Sun, Jun 28, 2009 at 12:02:30PM -0400, Jeffrey Hutzelman wrote:
> >... therefore: cache derived keys in those handles and leave
> >krb5_keyblock and all existing references to it alone.
> 
> That seems a reasonable approach.

I wish we'd thought of it years ago :(

> >This may mean _adding_ new APIs that take derived keys (for implementing
> >the GSS-API mechanism's per-token message functions, and for the
> >krb5_mk/rd_priv/safe/cred() functions.
> 
> ... and for external users that might benefit from such caching.

Sure, adding a replacement for krb5_keyblock and full complement of APIs
(including types) that deal in it would be fine, but it'd be a plus, not
a requirement.

> >I don't think anyone will want session keys in tokens.
> 
> Application session keys, no.  TGT session keys, maybe.  Or at least,
> in something that presents the same interface as a token: you tell it
> the key once, and never get it back, but it does crypto operations for
> you.

True.  This would have zero impact on the scheme I proposed (but really,
it's Love's proposal).

> >  As for deriving
> >keys from non-extractable key material stored in tokens, that is
> >problematic.
> 
> That depends on the derivation in use.  The key derivations used in RFC3961 
> and RFC3962 all depend on either using the source key as an encryption key 
> or (for single-DES) are the identity mapping.  Both forms can be 
> implemented with a non-extractable source key stored in a token, provided 
> the token is willing to do encryption operations with that key.

D'oh, yeah, you're right.

Nico
--