Proposal for a Desktop Neutral Crypto API

[Nate Nielsen]

Brad Hards wrote:
> I'm not sure it is implementation neutral - that XEmbed socket artifact shows 
> an implementation bias.

True, but it allows any toolkit that supports this standard to
participate. Writing it as a shared library ties us to one
implementation in one toolkit.

>> - High level and simple API.
> 
> Sure, but very narrow focus - see below.

Right, I should have outlined that more clearly. This is about public
key encryption and making those comlpexities simpler for a user.

We already have the other bases covered. If a browser needs to encrypt
it's 'wallet' then we have that working pretty well.

This isn't a proposal to rip out any and all crypto and replace it with
a DBUS API. This is simply about public key encryption.

I've updated the Wiki page to reflect this.

>> - Continuity in the user experience.
> 
> I can't really comment until we see how many apps implement it. Also, because 
> the focus is so narrow, I'm not sure that can work anyway.

For starters seahorse will probably implement something like this.
Seahorse has had a goal of being very deeply integrated into the desktop
and simple to use. The latest code in CVS is starting to meet that
criteria.

We're taking the 'jargon' and complexity out of public key encryption.
Making so that your average user can feel comfortable using it. This API
is one aspect of that goal, and I believe other applications and
desktops can benefit.

As noted above, other areas of crypto in on the desktop (such as an
application needing to do arbitrary encryption of some file behind the
user's back, and prompting for a password etc...) are already simple for
the user to use. This API does not cover those cases.

The reason for posting it is to see the potential problems with a public
key crypto API like this. Obviously not everyone is going to go out and
implement it tomorrow, but by getting some feedback incorporated early
on, it increases the chances of it gaining traction.

> The limitation to public key encryption was completely lost on me. It wasn't 
> mentioned in the original email and it isn't on the wiki. KDE needs 
> encryption for a whole stack of functionality (wallets, SSL, and then 
> application specific stuff, like the OpenOffice file format encryption). You 
> really need to make the intended goal clearer.

I had no idea that the general state of arbitrary and application
specific encryption on the desktop was in such desperate need of
replacement. Consistent use of incredibly fully featured libraries such
as openssl could solve this problem, IMO.

Again, this was not the intended goal, and I should have been clearer in
the proposal. It's now been updated. Thanks for bringing that up.

> If it is going to be interoperable, you need to say what formats must be 
> handled. Do we have to do PEM? Do we have to do binary DER?

Any and all formats pertaining to a given public key encryption standard
should be handled by the underlying implementation. In the case of
S/MIME PEM, DER and PKS12 and probably others would be handled.

It's the user who is going to receive these keys via email or some other
high level communication, and the client of the API calls into it, on
the users request, to import the key into their local keyring /
certificate store.

> OK, so if I want to do HMAC for an integrity check, I'm back to an application 
> specific mechanism to put the keys in? That isn't really solving the stated 
> goal of continuity in the user experience IMHO.

But in this case the key would be application and protocol specific.
There would be no need to share the keys between applications. Please
see above.

>>Perhaps I'm missing something on the security though. Was there a
>>specific security flaw or short coming you've thought of?
> 
> You have to pass the plaintext information across it. Sure, the keys are 
> hidden away, but that isn't the whole problem.

Again these are high level uses we're talking about. Not low level
application specific encryption. In our use cases plaintext has already
been passed all over the place, most notably to the XServer, in the
email client, probably cached to disk.

During public key encryption it's also going to be passed again into the
programs that perform that encryption. Passing the plain text over a
simple unix-socket (ie: DBUS) isn't going to make matters worse.

Also as noted in the email to Mike Hearn, we could add an interface
where the plaintext/cipher does not go over DBUS along with all the
other information.

BTW, thanks for taking the time to look this over. It really does help
to get other perspectives.

Cheers,
Nate