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
(http://www.gnupg.org/gpa.html) 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
choices:
* 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
yet.
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
done.
--
Werner Koch GnuPG key: 621CC013
OpenIT GmbH http://www.OpenIT.de
--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org
> 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
(http://www.gnupg.org/gpa.html) 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
choices:
* 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
yet.
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
done.
--
Werner Koch GnuPG key: 621CC013
OpenIT GmbH http://www.OpenIT.de
--
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of "unsubscribe" to gnupg-users-request@gnupg.org