[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