Proposal for a Desktop Neutral Crypto API

[Nate Nielsen]

Mike Hearn wrote:
> Hmm, why is this a "DBUS API", which forces the use of IPC instead of a
> shared library? I don't think using a separate process for doing things
> like encrypting text blocks is wise from a performance perspective. 
> 
> I might have misunderstood the goals of this service though.

Well, here's some of the reasoning behind that. Many of the following 
are things that can be accomplished with a shared library, but are just 
so very much simpler when approaching it from a clean DBUS service 
perspective.

- Caching of security sensitive information, in one or a pair of
   processes rather than many. This process can be designed to
   protect passphrases and the like. Things like starting the process
   setuid root, (and then dropping all privileges) allow the implementor
   to use non-pageable memory.

- A continuity in the encyption experience which allows notification
   icons (let's say for cached passphrases, log output windows), and the
   like.

- To allow the various implementors to use different toolkits and
   libraries and to avoid implementation details and requirements
   leaking. This allows each desktop to implement the API according to
   their own coding style. An important factor if this is to gain
   traction in the myriad of applications that require encryption
   services.

- It's clean and simple. Doesn't bring dependencies into the calling
   program. Allows swapping of implementations when the user / admin /
   distro requires. It's much more flexible and allows new features to
   be developed independently of the API.

- Allows the simple integration of encryption hardware, like biometrics
   or card readers.

- It makes real time updates and state information real easy. Say the
   user adds a new key, it should show up immediately in whatever apps
   are displaying key lists. Sure a library could do this, but would
   involve an internal IPC connection as well as a daemon running
   anyway.

- Performance: Most of the current Linux encryption packages (ie: gpg,
   gpgsm) already use IPC exclusively. You'll also note there's two sets
   of encryption interfaces. One is text based and the other file based.
   Performance aspects of the API proposal can be fine tuned easily
   (perhaps with a third unix-socket based interface?). In any case this
   is a problem that can be solved regardless of IPC.

Given that many applications and desktops already each have their own 
encryption solution going, an effort like this needs to be as 
transparent and simple as possible implementation-wise in order to go 
anywhere.

Cheers,
Nate