Aren't there a lot of existing "Keychain" (os x has one, and I think
redhat does too) applications that hold all sorts of things in a
daemon?  Is this any safer than a library which can access a protected
database of some type?

On 10/17/05, Steven M. Bellovin <smb@cs.columbia.edu> wrote:
> In message <4353D897.3070505@asgaard.homelinux.org>, =3D?ISO-8859-1?Q?=3D=
22Nils_O=3D2
> E_Sel=3DE5sdal=3D22?=3D writes:
> >Matthias Buelow wrote:
> >> Jan Schaumann wrote:
> >>
> >>
> >>>     BPG, the BSD Privacy Guard, is a BSD-licensed program that
> >>>     performs authentication and encryption using the OpenPGP standard
> >>>     (RFC 2440).  The BPG project's goals were to produce:
> >>>
> >>>     * A set of libraries for signing and encrypting data, allowing th=
e
> >>>       integration of OpenPGP features in other applications.
> >>
> >>
> >> What is the rationale behind this? I assume you are aware of entry #4.=
16
> >> in the GnuPG FAQ, "Can't we have a gpg library?"?
> >>
> >> While I don't know the whole argumentation against a PGP library, one
> >> (imho) strong argument is that a library would load the decrypted secr=
et
> >> key into any random application's memory that uses pgp functionality
> >> (like a mail reader), while with a separate pgp/gpg binary, it will
> >> reside only in the address space of the pgp/gpg program, which has bee=
n
> >> designed (and carefully checked/hardened) for this situation.
> >
> >Perhaps an idea would be to modelle it after
> >http://cm.bell-labs.com/sys/doc/auth.html
> Atleast the idea is that all sensitive processing is done in the context
> >of a trusted process, and you can very well have libraries interfacing t=
hat.
> >Or perhaps I BGP already does this ?
> >
> Keeping keys away from user programs is certainly a good idea.  The
> issue with using a daemon to hold the keys is how to authenticate
> connections to the daemon.  Furthermore, if one can launch, say, a
> buffer overflow attack on an application, it's not a lot harder to use
> your injected code to call the daemon on the attacker's behalf.
>
>                 --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>
>
>