Version 3 (modified by Daniel Kahn Gillmor, 10 years ago) (diff)


Cryptographic Agents

One useful technique for cryptographic security is to limit access to your primary secrets (private keys, passphrases, etc) to a single software process, often called an "agent". The agent can communicate with other processes using a simple interface to allow cascaded access to the secrets as needed.


The advantages to an isolated cryptographic agent are similar to the reasons for the classic Unix Philosophy.


Because the process which holds the secrets is relatively limited functionality, it's easier to review the source code of the agent itself. This means that you can be more sure that it's handling your secrets securely. Because it's not trying to do too many other things, it has fewer places to fail.


Because access to the secrets go through the defined interface to the agent, there is an opportunity to log all access attempts. This allows you to audit the use of the agent.


Your security needs might change as your habits develop. By requiring all access to secrets to go through the agent, you can change the rules for distributing access in a simpler, central location. Require user confirmation for access to your private keys? Just modify the agent.

Existing Implementations


ssh-agent is distributed with OpenSSH.


gpg-agent is offered by the GnuPG folks. It offers an agent for use with gpg and gpg2, and is also capable of emulating ssh-agent.


gnome-keyring is the GNOME environment's default daemon. It claims to offer a range of features, including ssh-agent emulation.


kwallet is KDE's offering.


wallet is offered by Russ Albery of Stanford, and focuses on kerberos 5 authentication.

Agent Collisions

Many of the above-listed programs have slightly different interfaces. Often, one will attempt to offer the interface of another, to reduce the number of agents in use. But this can lead to problems when the new agent isn't able to support the full functionality of the agent it's usurping.

This happened to me (dkg) on squeak on 2008-04-17, when i upgraded gnome-keyring to 2.22.1-1. The new gnome-keyring automatically started up at my next session, and began offering an ssh-agent-style interface, despite the fact that the gnome-keyring-daemon was unable to handle the smartcard information that i usually pass to ssh-agent. Since there was already something offering ssh-agent info (i.e. the SSH_AUTH_SOCK environment variable was set), ssh-agent declined to start with my new session. I repaired this by disabling gnome-keyring's ssh features for my own user account. I did:

gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false