Windows IPC (was: Pb decrypting with PGP 6.5.3 and GnuPG)

Werner Koch wk at
Thu Aug 31 12:02:08 CEST 2000

On Thu, 31 Aug 2000, Mr Griffon wrote:

> Well in fact I had already started designing a neat Windows frontend for 
> gnupg, with all the bells'n whitles (Win98 style toolbars, etc...). Then I 

BTW, we are working on GPA and this runs also as a native Windows
program.  However, there are quite a lot of things we have still to do
( and we do not need legal papers for GPA.

> found out that the current version of GnuPG for Windows has absolutely NO 
> way of getting the secret key password from another program. This means 

I have not yet implemented it but for other reasons (see below) but it
should be fairly easy to do;  You can do it the same way as in Unix:
use --passphrase-fd and specify the handle from a pipe you have
created (see W32's CreatePipe()).  We are already using 2 pipes for
the output and the status stream (gpa/gpapa/gpapaintern.c).  I am
currently reworking that part but the code is still there.

A better way to pass the passpharse to gpg is by using a special
program called gpg-agent which provides a cache for the passphrase and
can pop up a window to ask for a non-cached passphrase.  GnuPG 1.1.1
has already implemented that adn I am currently looking for a good IPC
mechanism to be used uner Windows (we use Unix Domain Sockets in the
Unix version).  As far as I have found out there are several possible 

  * Mailslots do provide a connectionless IPC which is not so nice and
  afaik there seems to be a way to access them over the network which
  is not good.
  * Named Pipes are the most elegant solution to replace sockets but
  they are accesiible of the network and I have not yet seen whether
  there is a way to deny all connections from the network.
  * Shared Memory is implemented using a mmap style thing and that
  seems to be the only solution which is not accessible from outside.
  However, the docs I have do say that anonymous shared memory (File
  Mapping) is preferrable written to a swap file - something we don,t
  want.  Hmm, would need encryption after doing DH key exchange - not
  so nice.
  * Write a device driver to have non-swappable memory; however this
  needs to cope with all the NT security things.  This would be nice
  anyway because we do not yet have non-swappable memory on Windows
It is essential that at least the transport of the passphrase from one
process to another is secured in some way.  gpg itself does make sure
that the clear passphrase is only stored as long as needed. Passphrase
caching without non-swappable memory is a thing which should not be

Werner Koch				GnuPG key:  621CC013
OpenIT GmbH                   

More information about the Gnupg-devel mailing list