Subject: Re: NetBSD and the Google "Summer of Code" Summary
To: Steven M. Bellovin <email@example.com>
From: matthew sporleder <firstname.lastname@example.org>
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 <email@example.com> wrote:
> In message <4353D897.firstname.lastname@example.org>, =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, http://www.cs.columbia.edu/~smb