Project review: encryption performance

[Nicolas Williams]

On Tue, Jul 21, 2009 at 04:26:23PM -0400, Greg Hudson wrote:
> On Tue, 2009-07-21 at 13:41 -0500, Nicolas Williams wrote:
> >    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

On some project page.  IMO it belongs in this one.

> 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.

That's fine, and very good too (there's no need for loadable crypto
modules here).

> 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.

Yes, but back to the internal non-copy constructor you mentioned: I
don't see how to get what you had in mind with PKCS#11, as one way or
another you'll be moving key bytes around.  Perhaps you should not
mention the non-copy constructor, as that makes my concern go away :)

> 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.

*nod*

Incidentally, NSS itself uses PKCS#11.

> >  - 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.

True, but internal uses of it might not deal in protocol keys.

> 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.

Right, that would address my comment.

> >  - 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.

This probably applies to the internal constructor you mention above.

> >  - 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.

Heh.  Thanks,

Nico
--