Project review: encryption performance

[Greg Hudson]

On Tue, 2009-07-21 at 13:41 -0500, Nicolas Williams wrote:
>    Presumably the crypto plug-in has to be invoked to initialize the
>    internal krb5_key.  Can that be generic enough that a "non-copying
>    keyblock-to-key_st converter" is feasible?  And why does it matter
>    that it be "non-copying"?  Do you expect a key copy operation to be
>    slow?  (Key, not key schedule...)

It might not be a meaningful performance savings.  I may do some tests
and throw out the non-copying constructor idea.  I just didn't want to
slow down the krb5_c_encrypt type operations by doing unnecessary
allocations and copies.

>  - The SPI has to be public too, to some degree anyways.

I've changed the word "SPI" to "vtable" in my project proposal to avoid
confusion.  The enctype, enc_provider, and hash_provider vtables are for
polymorphism of different algorithms, not different back end
implementations.

>    Can you include a definition of that SPI in the project page?

You mean in the crypto modularity project page?  (Since this has nothing
to do with the encryption performance project.)  I can't speak to
Zhana's plans in that level of detail.  The back-end SPI may be a bit
messy since different libraries implement different bits of
functionality.

Also, just to be clear, the crypto modularity project is about
compile-time back end selection of crypto implementations.  The current
plan does not involve using the plugin layer or doing dynamic loading.
The "SPI" will consist of defining the same function names in different
ways in different source files.  It may not be necessary to have precise
documentation if the proof-of-concept glue layer can act as an example.

The flip side is that we would probably be willing to accept a PKCS#11
back end glue layer (to live alongside the OpenSSL or NSS glue layer we
do ourselves) if one is contributed, so Sun wouldn't have to maintain
the code as a patch against upstream MIT krb5.

>  - krb5_k_create_key() should probably know whether the given key can be
>    further derived (i.e., if it is a protocol key).

krb5_k_create_key is an externally visible API.  From that perspective,
all keys are protocol keys, right?  I mean, you can only use them with
functions like krb5_k_encrypt which accept a key usage.

If there is an implementation reason to keep track of when a key won't
be further derived, we can add an internal constructor which keeps track
of that.

>  - For implementation of keyblock-based functions you might want the
>    initializer to take a flag saying "don't bother caching derived keys,
>    key schedules, or anything else" (since that might mean allocating
>    memory you'll free right away).

Yes, we'll want to disable caching for krb5_c_encrypt and friends.  I've
added a note.

>  - You might want to mention PKCS#11 as a possible crypto provider, not
>    just OpenSSL and NSS.

I assume you again refer to the crypto modularity project.  We will
almost certainly be implementing a proof-of-concept glue layer for
either OpenSSL or NSS as part of that work, so where we mention those
two, it doesn't make sense to add other options.  I added PKCS#11 to the
earlier parenthetical which also mentions Bsafe, although that wasn't
intended to be an exhaustive list.