Subject: Re: NetBSD and the Google "Summer of Code" Summary
To: Steven M. Bellovin <>
From: matthew sporleder <>
List: netbsd-users
Date: 10/17/2005 14:10:38
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 <> wrote:
> In message <>, =3D?ISO-8859-1?Q?=3D=
> 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=
> >>>       integration of OpenPGP features in other applications.
> >>
> >>
> >> What is the rationale behind this? I assume you are aware of entry #4.=
> >> 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=
> >> 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=
> >> designed (and carefully checked/hardened) for this situation.
> >
> >Perhaps an idea would be to modelle it after
> >
> 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=
> >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,