[Gpg4win-users-en] How do I prevent dirmngr.exe from starting up and running in the background?
Bernhard Reiter
bernhard at intevation.de
Fri Sep 5 09:41:02 CEST 2014
Hi David,
On Thursday 04 September 2014 at 13:01:07, David Kronlid wrote:
> Perhaps you could insert a choice during the installation process? OpenPGP,
> S/MIME or both.
I don't think the effort is worth right now, there are things to do with a
higher value for users. And (see my other email) dirmngr will change anyway
and most likely be necessary for OpenPGP as well.
> I would guess that most people never use S/MIME
I don't have good data on this. Personally I use S/MIME with GnuPG a lot,
I know others which which this is the same. Of course I also know people that
only use OpenPGP.
> and that having unnecessary
> services running in the background will be of no use to them. I have plenty
> of RAM and CPU on my computers so the only problem I have maybe once or
> twice a year is that DirMngr crashes, but I can live with that as GPG4Win
> is free. But as there are plenty of services running in the background both
> on Windows and Linux slowing hundreds of millions of computers down daily,
> why not give the users a choice if they want to enable S/MIME related
> services or not?
For a single user system you are probably right. The design of the GnuPG
crypto suit aims at many platforms, including multi-user platform.
On a multi-user platform where many crypto operations are done, the dirmngr
service will actually lower the load and raise speed, as it will cache
request for all users and only is one process for several requests.
Including a variant for single user machines will raise software complexity
and thus costs for maintaing the while package.
> My guess is that S/MIME mostly is in use inside larger companies and
> organisations because it facilitates the work for IT admins? For normal
> users OpenPGP would probably be the first choice right?
In my experience, once set up, S/MIME is a lot easier for users, because
they do not have to deal with many evaluations of trust relations. The trust
relations are the hardest part for the users. I am communicating with a
number of smaller organisations with S/MIME as well. In one example I can
even send the secretary and encrypted email because it is just set up to
work, so he can just decrypt it.
So it depends on whom you want to communicate with.
> PS. Chris, I don't think we as a security focused community should discuss
> software based on conspiracy theories. If we have proof that something
> leakes to NSA, then we should say it openly to the whole world. But let's
> not insinuate things about security software just because we don't know
> what it does. The Swedish and German programmers that have created DirMngr
> have probably no interest in providing information to NSA and such. Using
> GPG is most likely far more secure than not using it.
We try our best, but in security you should trust your own judgement not ours.
It is true that if you communicate over the internet, you can be monitored.
So when downloading a certificate or certificate validity information.
Dirmngr does just this. But it makes S/MIME more secure by default than
OpenPGP, because X.509 has embedded standards for checking certificate's
validation, e.g. via revocation lists or OCSP. You can also do this with
OpenPGP, but there it is non-standard.
By caching this validity information, dirmngr actually avoids that a request
per certificate usage is send. Thus it hides information from an external
observer.
In short: Proper dirnmngr use will reduce the information that can be
externally observed.
Best,
Bernhard
ps.: Let me know if this post is too involved.
--
www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member)
Intevation GmbH, Osnabrück, Germany; Amtsgericht Osnabrück, HRB 18998
Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3955 bytes
Desc: not available
URL: <http://lists.wald.intevation.org/pipermail/gpg4win-users-en/attachments/20140905/a4804018/attachment.bin>
More information about the Gpg4win-users-en
mailing list