Proposal for a Desktop Neutral Crypto API

[Brad Hards]

On Sat, 2 Apr 2005 18:21 pm, Nate Nielsen wrote:
> 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
I'm not sure it is implementation neutral - that XEmbed socket artifact shows 
an implementation bias.

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

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

>  - Security.
See below.

> And for the details of the above:
> http://lists.freedesktop.org/archives/xdg/2005-April/006429.html
I'll comment on that email in context, with a separate email.

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

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

> > * 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?
Its an argument against a central server. The easy answer is a shared library 
and application specific trust, but I guess that isn't what you wanted to 
hear...

> > * 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.
See above.

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

> 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?
You have to pass the plaintext information across it. Sure, the keys are 
hidden away, but that isn't the whole problem.

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050402/1e570e4a/attachment.pgp