Proposal for a Desktop Neutral Crypto API
bradh at frogmouth.net
Sat Apr 2 11:54:40 EEST 2005
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
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.
> And for the details of the above:
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
> > * 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050402/1e570e4a/attachment.pgp
More information about the xdg