[RFC] kdb: store mkey list in context and permit NULL mkey for kdb_dbe_decrypt_key_data

Sam Hartman hartmans at MIT.EDU
Sat Sep 11 15:55:31 EDT 2010

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> For purposes of discussion, I want to call out the performance
    Greg> impact.  Currently, the caller of krb5_dbe_decrypt_key_data is
    Greg> required to identify the correct master key using the entry's
    Greg> tl-data.  Unfortunately, that tl-data is not available to
    Greg> krb5_dbe_decrypt_key_data given its current API, so it will
    Greg> try all master keys in order.  During a master key transition,
    Greg> that will result in some extra decrypt operations on a running
    Greg> KDC.

    Greg> We can re-optimize this case by adding an optional argument to
    Greg> krb5_dbe_decrypt_key_data for the full DB entry, and passing
    Greg> that argument at all performance-sensitive call sites where we
    Greg> pass a null mkey.  As I told Sam earlier, I am happy
    Greg> considering that re-optimization to be future work, and think
    Greg> we might be able to fit it into the margin for 1.9.

O, if you don't mind it being an optional argument, it's relatively
easy, and I can try to fit into my margin.  The code for
decrypt_key_data becomes cleaner (removes the loop and the non-cleanup
goto) if you make it mandatory.
Reworking the call sites in kadmind for that was a bit more than I
wanted to do.

note that for principals where the principal is encrypted in the current
master key there is no performance impact with this code.

More information about the krbdev mailing list