Gpg4win Wishlist

This page is intended for feature ideas and descriptions that could be implemented in the future. Linked from Wishlist, also see ImprovingSecurity

Crypto in general

x509: access windows certstores

Windows already has a "keystore" for x509 certificates, for some settings it would be good if this store could be read in from Gpg4win (the components dirmngr and gpgsm).

Won't happen because Microsoft controls this store and may add new certificates without notice. -- Werner Koch 2015-11-27 14:21:53

I think this might be added as an Option. While it is correct that Microsoft controls this store this is basically the baseline system trust so you might also want to use it for certificates as attacks are already possible when an attacker controls such a certificate you won't lower security but you would improve usability. -- Andre Heinecke

long shot email idea: encrypt as message/rfc822

The headers of emails may contain more information than many people would like to reveal. A standard conforming method to send these emails is to just attach the full email as message/rfc822 type and encrypt the result. Email client with MIME support will already display it. So they only missing link is to add a convention that the subject line and reciepients of the attached email will be used and display when an email is read. Would be nice to try this concept and implement it in Free Software clients like mutt, Kontact Mail, claws, (a fork of) Thunderbird.

add GnuPG as "cryptographic service provider" (CSP) and MIME/filter

see, Needs more evaluation. Could possibly enable other application to access some GnuPG features.

Sorry, this is BS. We can't provide an alternative to the platforms standard encryption facilities by making our own a part of it. The overall goal is to avoid the use of proprietary code as far as possible. BTW, we actually make use of the CSP to mix in some random into our own RNG; this might be helpful but it won't harm. -- Werner Koch 2015-11-27 14:21:53


Make it easier to create of keys larger than 3072 bits?

Some people wish that Gpg4win/GPA should make it easier to create RSA keys with more than 3072bits, especially 4096 bit keys that seem to be popular for new certs in some circles. If so, it would be done in the advanced configuration "create new key" input GUI. Others believe that 2048 bit is a sane default, for the discussion see LargeKeys.

Nope. A GUI should actually not have a way to tweak parameters. This is for expert users with enough knowledge and training to evaluate their security needs. A part of that training should be the use of the command line. -- Werner Koch 2015-11-27 14:25:09


Also see KleopatraHackability.

Guide first time users

When starting Kleopatra for the first time on Windows it currently starts up with an empty Window and users may felt lost or may not know what do to next. Kleopatra should give users an idea what to do next, e.g. generated a certificate or configure some keyservers.

Improved Smart Card handling

GUI for Revocation certificates

Kleopatra should allow you to generate and publish a revocation certificate for your certificates. Planned to be implemented with Gpg4all2015.

Additional localizations

Kleopatra is KDE Software and thus available in 50 Languages. There could be optional "Language pack downloads" made available for those languages or at least for all the languages that the Gpg4win installer supports.

Better certificate selection dialog

The selection dialog could be improved. The default view should be very simple, but showing something that motivates people to look into the second and third layer of information. Ideally the display of the first two layers should be integrated in the email application.

  1. Layer: Just a graded information how well the fit of certificates is.
  2. Layer: Showing the accumulated information per email address.
  3. Layer: Showing the default information per email, address like encryption method, last contact via the certification, trustlevel, grade of algorithms.
  4. Hide untrusted (expired) keys by default and only show them on request.

Ability to decrypt files that do not have the .gpg extension in their filename

As of Feb 2014, trying to decrypt a file without the .gpg extension results in the somewhat missleading error message "Could not determine whether this is an S/MIME or an OpenPGP signature - maybe it is not a signature at all?"

Report hints

Trying to import a certificate with an MD5 has signed user id fails because "gpg: Note: signatures using the MD5 algorithm are rejected", it seems this "note" is not displayed, but it should so the user can diagnose this case. post on users-list

Integration in the gpg4win build system

Currently in progress in the kleo-kf5 branch of Gpg4win.

Clipboard: Integrated Sign&Encrypt support

User may want to use the clipboard for encrypting and signing text (as it is possible with files) to be able to secure confidentiality and integrity. For a description of user problems with Gpg4win 2.2.4 see

Clipboard: Support through command line argument

You can define system wide shortcuts on Windows that start a program with some command line arguments. This could be used to create a shortcut to encrypt / decrypt your clipboard. Ideally these shortcuts would be configurable in Kleopatra itself. But it might be a cool feature for advanced users that we could document in the compendium. The time needed to implement this would be less then a day as it would be just adding some command line arguments. And a workflow that includes shortcuts to encrypt / decrypt could be useful.

Clipboard: Add support for files

Currently kleopatra only offers the clipboard options if text is in the clipboard. While tecnically this is currently necessary (as the jobs for "non-mime" mails are used in the clipboard implementation) technically there should be no reason why this shouln'd work with files too.

Support for secret keys in a different location for GpgOL and GpgEX

People may want to save their secret keys or their complete crypto setup on removable devices. While Gpg4win already supports creating a "portable" version, this version does not support GpgOL and GpgEX and it would be a plus to have the properly installed version read only the secret keys from the removable filesystem device. It is already possible using options for keyring or the GNUPGHOME environment variable, however if many people want to use this, guided support from a GUI would be an improvement.

See wald thread 1656


This list relates to GpgOL 2.0 as it will be part of Gpg4win-3.0 with full mime support etc.

Key creation

For a better initial User experience GpgOL could have some more Features regarding key creation:

Initial Key creation

If Outlook is started with GpgOL active and there are no secret keys for any of the configured accounts GpgOL should detect that and offer to generate keys, taking the name and e-mail from the account settings.

Backup nagging

If GpgOL has created a key and it is used to encrypt for some time e.g. 10 encryption GpgOL should start to nag the user to make a backup and offer to print / export the secret key. As long as the user explicitly confirmed that a backup was made. GpgOL should make it clear that you can't read your mails anymore if you loose the key or the password.

Key creation after account setup

If a new account is added and there is no private key for an account GpgOL should offer to create one.


GpgOL should support publishing a key through a Web Key Service.

Easier default configuration

The default configuration or at least a setting in GpgOL should affect trust model (tofu+pgp), auto-key-locate and auto-key-retrieve.

Improved change handling

Currently changes to categories or to flag a message is not supported while the message is in a decrypted state. There might be solutions to that which need to be investigated and tried out.

Show contents during signature verification

While verifying a signature GpgOL should already show the unverified content of the message. This is especially important if auto-key-retrieve is enabled and key retrieval takes some time.

Encryption without Kleopatra or GPA

GpgOL currently only needs Kleopatra on Encryption for the Certificate selection dialog. GpgOL could implement certificate selection itself and so get rid of the dependency to Kleopatra or GPA.

This would have several advantages:

Address book integration

It should be possible in the addressbook to configure encryption keys and preferences.

Minimal integration

An Idea for a simple minimal integration that would allow Address book integration could be to just use Attachments on Contacts. E.g. if a Contact has an attached file with name encryption-key this key could be imported and used for that Contact automatically.

Opportunistic encryption

GpgOL should offer opportunistic encryption (toggle encrypt/sign) if there are valid keys for all recipients.

Saving decrypted copies

It could be an option to save a decrypted copy of a mail or multiple mails in a different folder.



Website / Documentation

Explain the processes on Windows

.. so that people know what processes run there and why they are running. Best way would be a diagram. (For example see this wald post where a more explanation would be useful.).

Howto to make x509 root certificates trusted

Similiar to the hints linked from X.509, but specific for a modern Gpg4win. (Will probably need an update once GnuPG 2.1 is packaged.)



Improved Encoding handling

File extension handling:

Gpg4win should register file extensions like .asc .gpg .pk7 etc. and open an appropriate Software / Dialog to handle those files when they are double clicked in the Windows explorer. FWIW, gpgme now has an identify feature which works similar to file(1) by looking at the content of a file. As of now it is able to detect binary CMS message and armored PGP messages. We should extend that to binary PGP messages.

Comprehensive Video Tutorials

It would be nice to have a set of clear and short Video tutorials that explain a single use case. With the idea that you can link to those if you want to send someone a short "User friendly" explanation how they can securely communicate with you. Some ideas:

Or Webinars

It seems some people would benefit from an interactive walkthrough to some of the usually stages. Or an interactive question and answer session with screencast (== webinar/webworkshop? :) )

Remove necessity to reboot in the installer

The Gpg4win installer should get a proper handling of running processes and make sure that everything is killed correctly when updating / uninstalling so that the Windows 98'ish "Reboot Now" will usally not anymore happen. (May be a bad idea if we need to close the file explorer.)

Display the GnuPG engine logo more prominently

There are probably few places where the GnuPG logo should be visible in addition in Gpg4win. The idea behind this is that GnuPG can do many things and Gpg4win should point out that it is fully included and strengthen GnuPG's recognition.

Ready for distributions via app-store or digital distribution platforms?

Digital distributions platforms like Steam or the Windows v>=8.1 app-store can help with

It makes sense to check what would need to be done to distribute Gpg4win over wide spread digital distribution platforms. This usually includes a technical, a financial and a licensing/condition part that need to be clarified.

Support or technical preconditions for supporting Windows 10

As many users get exposed to the coming with Windows 10 operating systems, it would be cool to see if it could be supported with MIME aware crypto mail. If we cannot support this mail app, we could list the technical preconditions so that maybe the mail app developers will make this possible in the future,

Gpg4win/Wishlist (last edited 2017-01-09 08:57:53 by bernhard)