Proposal for a Desktop Neutral Crypto API

[Nate Nielsen]

Brad Hards wrote:
 > Apart from the "remember what we did last time", I'm not sure what
this is
> meant to provide in terms of additional functionality over what could be done 
> with a shared library. Can you explain what you are trying to achieve by a 
> crypto API? If I understood that, I might be able to make a more informed 
> comment.

Sure. I've outlined the main benefits over a shared library in a
previous email to the xdg list.

To sum it up:
 - Desktop, license, implementation, coding style and implementation
   neutral
 - High level and simple API.
 - Continuity in the user experience.
 - Security.

And for the details of the above:
http://lists.freedesktop.org/archives/xdg/2005-April/006429.html

> First look over:
> * why the choice of key types (openpgp and smime)?

This is a system for public key encryption, which is what users use when
communicating with others. OpenPGP (with it's keys, web of trust) and
S/MIME (it's underlying certificates, authorities) are the two main
methods of encrypting person to person communications.

> * are you trying to replace existing key agenst (eg for ssh or GPG)?

That's up to the implementation. Seahorse for example has
'seahorse-agent' which is a GNOME integrated GPG agent. But that has
nothing to do with this API per se.

> * what is the format for org.freedesktop.Crypto.Keys.ImportKeys and 
> ExportKeys?

That depends on the key type. PGP has a format (ASCII armor, and raw key
file) for distributing public keys as does S/MIME with it's PEM (and
otherwise) encoded certificates. This API would work in either case.
Although perhaps the arguments shouldn't be STRING, they could be
changed to a byte array for maximum flexibility.

> * how do you handle usage specific trust (eg I trust a certificate or key for 
> a game server, but I wouldn't trust that certificate for my online banking)?

Good point, one that probably needs more thought involved. Any suggestions?

> * org.freedesktop.Crypto.TextOperations.EncryptText() and .DecryptText() 
> appear to be pretty GPG centric. What if I want to encrypt with Blowfish, CBC 
> mode, with a specific IV, PKCS7 padding?

Those are symetric encryption algorithms. This API centers itself around
public key encryption. The public key encryption (and certificates
etc...) is currently very confusing for users. This proposed API hopes
to bring a simplicity and continuity to this area.

> * same for TextOperations.signText and VerifyText. What if I just want to do 
> HMAC using SHA256?

Again, think public key (assymetric, whatever) encryption. This API is
about users communicating with each other, and encrypting that
communication.

I guess if there's a demand for arbitrary symmetric encryption, then
this could be added. But this part seems to fit more into a low level
library (ie: openssl) rather than a high level API.

> * are you confident that DBUS is secure enough for this?

The whole point of this API is that nothing sensitive crosses the DBUS
API. It's all contained within the one implementing process and it's
underlying crypto engines.

Perhaps I'm missing something on the security though. Was there a
specific security flaw or short coming you've thought of?

Cheers,
Nate