Project review: encryption performance
Nicolas.Williams at sun.com
Tue Jul 21 17:23:28 EDT 2009
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
> 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
> 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.
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.
More information about the krbdev