FIPS certification
Nicolas Williams
Nicolas.Williams at sun.com
Sat Feb 28 16:23:47 EST 2009
On Sat, Feb 28, 2009 at 01:56:22PM -0600, Nicolas Williams wrote:
> On Sat, Feb 28, 2009 at 01:07:50PM -0500, Ken Raeburn wrote:
> > We'd also still need to handle the krb5_keyblock structure embedded in
> > krb5_creds; in that instance it wouldn't be extensible.
>
> I suspect we can handle that by having a new krb5_keyblock for all
> non-krb5_creds uses of it, and krb5_keyblock_old for krb5_creds. It's
> only the auth_context and the GSS mech where we need to be able to cache
> derived keys and what not (crypto library handles).
There is another way...
If we only care about performance in the GSS mechanism then there's no
need to change krb5_keyblock. That means crypto in the raw krb5 API
apps will not be as good, mostly because of the lack of derived key
caching and because of the lack of caching of crypto library handles
(including key schedules). But MIT krb5 already suffers from this
anyways.
Nico
--
More information about the Kerberos
mailing list