In message <4353D897.3070505@asgaard.homelinux.org>, =?ISO-8859-1?Q?=22Nils_O=2
E_Sel=E5sdal=22?= 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 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
>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 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