[Cryptography-dev] Thoughts on opaque key material.

[Glyph Lefkowitz]

On Apr 21, 2014, at 4:15 PM, David Reid <dreid at dreid.org> wrote:

> I apologize for how disorganized these thoughts are, the problems are more fully formed than
> the solutions and I ended up spending much more time than desired writing this email, so I just sort of cut myself off at 4pm.  Hopefully we can figure out some of these answers on the mailing list.
> 
> --
> 
> Currently RSA key material is represented as an object having a series of
> properties that correspond to the various mathematical components of an
> RSA key.
> 
> The initial reasoning for this is that it would make the internal
> representation of a key backend independent and allow for moving key
> material from one backend to another (for example, loading the key from one
> backend and performing encryption with another backend).
> 
> However, as an initial proponent of this argument I feel comfortable saying
> that I was completely wrong.  It has variety of negative effects,

(agreed on all points)

> Given these issues I think we must seriously consider switching away from
> these backend independent representations as our primary interface to key
> materials.  Preferring instead opaque backend specific implementations.
> 
> For example, instead of a concrete RSAPrivateKey instance which can be
> instantiated with the underlying components, I imagine all key generation and
> loading being mediated by backends and resulting in objects that provide much
> more narrow interfaces organized around what you can do with a key (instead of
> what a key intrinsically is).  For example, when generating an RSA key on the
> openssl backend you would get back an object which provides a basic interface
> indicating that it is an RSA key, that has some basic attributes for key
> size, and accessing the public key object, then methods for obtaining backend
> specific contexts for performing signing/verification and 
> encryption/decryption operations.

There's a conceptual shift here in what an RSAPrivateKey really is which you alluded to when you said (in the elided point 2 above):

> This is most notable with keys stored in a HSMs or SmartCards where it is a feature that you can not extract the RSA private key from the system

The really important point I think you're getting at here is that RSAPrivateKey is really a pointer to a key stored somewhere inside a backend.  Maybe you can't access the contents of that pointer in a particular way because the backend doesn't expose public APIs to do so.  Maybe you can't access it because it's physically isolated from the general purpose computer running Cryptography.  From an API perspective, it doesn't really matter; what the RSAPrivateKey interface should expose is the ability to do some crypto.  (And of course the "RSA" isn't here, this applies to any kind of private key.)

Maybe it would also be valuable, at some point, to have a backend-neutral representation of the values associated with an RSA private key, but that's more of an advanced feature and, at least at first, should be left to the backends themselves; they already have representations of this stuff they need to use, obviously, and the first and most important task is to expose it in a way which clearly reflects its capabilities.

> In addition to those basic operations the object may provide any number of
> backend specific serialization methods, potentially including "serializing" the
> key to something similar to the current interface (which we can think of as a 
> bag of bignums).  
> 
> In this way we can facilitate converting between backend specific key 
> representations through a process of serialization/deserialization (in many 
> cases through a formal specification such as PKCS#8).

I would suggest that the backend conversion process go like this:

Have a function that translates keys between different backends, that works for "any" key and "any" backend (scare quotes because they need to have some kind of common representation).
Expose an interrogation interface on the private key to allow the translation function to ask what formats its backend supports serializing to.
Expose an interrogation interface on the backend to allow the translation function to ask what formats new backend supports loading from.

The translation function can then be nice and general, and support any new formats that come along, and also order things by preference of efficiently (like, for example, the TotallyUnsafeMaybeTheMathIsWrongBagOfBignums format that would just move the bignums between backends, potentially including things like chinese remainder theorem optimizations, without re-verifying that they're accurate, since presumably the first backend that loaded it already did that in some way).

Anyway this all seems like a much better way to expose asymmetric crypto to me!

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140423/37aad1ad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4124 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140423/37aad1ad/attachment-0001.bin>