Proposal for a Desktop Neutral Crypto API
nielsen-list at memberwebs.com
Sat Apr 2 01:58:21 EEST 2005
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
- 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
- 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
- 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
- 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
More information about the xdg