[RFC] kdb: store mkey list in context and permit NULL mkey for kdb_dbe_decrypt_key_data
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> 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