Subject: Re: NetBSD and the Google "Summer of Code" Summary
To: =?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?= <firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 10/17/2005 13:52:07
In message <4353D897.firstname.lastname@example.org>, =?ISO-8859-1?Q?=22Nils_O=2
>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 the
>>> 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 secret
>> 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 been
>> 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 that.
>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