|
|
Subscribe / Log in / New account

Koch: A New Future for GnuPG

Longtime GnuPG maintainer Werner Koch has posted an update on the project, mostly focused on the new associated "GnuPG VS-Desktop" business that is, it seems, going quite well:

For many years our work was mainly financed by donations and smaller projects. Now we have reached a point where we can benefit from a continuous revenue stream to maintain and extend the software without asking for donations or grants. This is quite a new experience to us and I am actually a bit proud to lead one of the few self-sustaining free software projects who had not to sacrifice the goals of the movement.

He concludes with a request for individuals who have been donating to GnuPG to redirect their generosity toward another deserving project. This is good news; GnuPG ran on a shoestring for far too long.

From:  Werner Koch via Gnupg-devel <gnupg-devel-AT-gnupg.org>
To:  gnupg-announce-AT-gnupg.org
Subject:  [Announce] A New Future for GnuPG
Date:  Mon, 03 Jan 2022 08:19:26 +0100
Message-ID:  <871r1p1e2p.fsf__49588.9554427535$1641194935$gmane$org@wheatstone.g10code.de>
Cc:  Werner Koch <wk-AT-gnupg.org>

Hello and a Happy Gnu Year!

It has been quite some time since my last status report on GnuPG.  I
have been quite busy working on the project but unfortunately rarely
active on the usual channels.  So, here is a new report telling what we
did over the last two or three years.

Please read at least the last section.

A web version of this article is available at
https://gnupg.org/blog/20220102-a-new-future-for-gnupg.html


Some background
===============

  In the beginning GnuPG was a fun project I did in my spare time.
  After a few years this turned out to be a full time job and it was
  possible to acquire paid projects to maintain and further develop
  GnuPG.

  When the BSI (Germany's Federal Office for Information Security)
  migrated back from Linux to Windows, a need to migrate their
  end-to-end encryption solution, based on GnuPG and KMail, was needed.
  A call for bids for an Open Source solution was issued and our
  company, g10 Code, along with our friends at Intevation and KDAB
  received the contract.  The outcome was Gpg4win, the meanwhile
  standard distribution of GnuPG for Windows.

  It turned out that the software used in Germany to protect restricted
  data at the VS-NfD level, called Chiasmus, showed its age.  For
  example, the block length of 64 bits (like IDEA or 3DES) is not
  anymore secure for data of more than 150 MiB.  Also the secret
  encryption algorithm has not anymore the confidence people used to
  have in it and due to lacking hardware support it is quite slow.  A
  new call to bid for a replacement of that software was issued and we
  also with Intevation were granted the contract.  Our solution was to
  update GnuPG and its frontends Kleopatra and GpgOL.  After some
  thorough evaluation of our software (working title /Gpg4VS-NfD/) and
  the usual bureaucratic we received a first approval in January 2019.


Meet GnuPG.com
==============

  I have been working with Andre Heinecke of Intevation GmbH since about
  2010 on Gpg4win and some other projects.  With the foreseeable
  approval of /Gpg4VS-NfD/ Andre then left Intevation and took over 40%
  of the g10 Code shares from my brother (I am holding the other 60%).

  We started to make a real product out of /Gpg4VS-NfD/.  Thus we rented
  a new office to work desk by desk on this and hired staff for sales
  and marketing.  We introduced the brand /GnuPG.com/ to have a better
  recognition of our product than by our legal name /g10 Code GmbH/.
  The software itself was re-branded as /GnuPG VS-Desktop®/ and
  distributed as an MSI packet for Windows and as an AppImage for Linux.
  Except for customer specific configuration files /GnuPG VS-Desktop/ is
  and will always be Open Source under the GNU General Public License.

  We also keep maintaining /Gpg4win/ as the community version.  This is
  based on the the same source code as /GnuPG VS-Desktop/ but comes with
  more features due to the use of the latest development branch.

  The benefits for the customer to pay for /GnuPG VS-Desktop/ are: a
  commercial support contract, the guarantee of a long term maintained
  and approved version, customization options, community tested new
  features, and the per-approval required vendor for security updates.

  Also technically published for longer, it became only last year widely
  known, that the legacy Chiasmus software may not anymore be used for
  restricted communication from this year on.  For the administration
  and also for the industry two option exist to migrate away from
  Chiasmus: the proprietary GreenBone software from /cryptovision GmbH/
  and our Open Source software /GnuPG VS-Desktop/.


The rush towards GnuPG VS-Desktop
=================================

  Since summer 2021 the phones of our sales team didn't stop ringing and
  we could bring in the fruits of our work.  We were not aware how many
  different governmental agencies exist and how many of them have a need
  to protect data at the VS-NfD (restricted) level.  And with those
  agencies also comes a huge private and corporate sector who also have
  to handle such communication.

  Although we support S/MIME, the majority of our customers decided in
  favor of the OpenPGP protocol, due to its higher flexibility and
  independence of a centralized public key infrastructure.  A minor
  drawback is that for a quick start and easy migration from Chiasmus,
  many sites will use symmetric-only encryption (i.e. based on
  "gpg -c").  However, the now deployed software provides the
  foundation to move on to a comfortable public-key solution.

  In particular, our now smooth integration into Active Directory makes
  working with OpenPGP under Windows really nice.  We were also able to
  partner with Rohde & Schwarz Cybersecurity GmbH for a smooth
  integration of GnuPG VS-Desktop with their smartcard administration
  system.

  We estimate that a quarter million workplaces will be equipped with
  GnuPG VS-Desktop and provide the users state of the art file and
  mail encryption.  Our longer term plan is to equip all public agency
  workplaces with end-to-end encryption software - not only those with
  an immediate need for an approved VS-NfD solution.  This should also
  fit well into the announced goal of the new German government to
  foster the development of Open Source.


Kudos to all supporters
=======================

  For many years our work was mainly financed by donations and smaller
  projects.  Now we have reached a point where we can benefit from a
  continuous revenue stream to maintain and extend the software without
  asking for donations or grants.  This is quite a new experience to us
  and I am actually a bit proud to lead one of the few self-sustaining
  free software projects who had not to sacrifice the goals of the
  movement.

  Those of you with SEPA donations, please cancel them and redirect your
  funds to other projects which are more in need of financial support.
  The Paypal and Stripe based recurring donations have already been
  canceled by us.

     All you supporters greatly helped us to keep GnuPG alive and to
              finally setup a sustainable development model.

                              *Thank you!*



Salam-Shalom,

   Werner



p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users at gnupg.org mailing list.
p.p.s
List of Release Signing Keys:
To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these four keys:

  rsa3072 2017-03-17 [expires: 2027-03-15]
  5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

  ed25519 2020-08-24 [expires: 2030-06-30]
  6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
  Werner Koch (dist signing 2020)

  ed25519 2021-05-19 [expires: 2027-04-04]
  AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
  Niibe Yutaka (GnuPG Release Key)

  brainpoolP256r1 2021-10-15 [expires: 2029-12-31]
  02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
  GnuPG.com (Release Signing Key 2021)

The keys are available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

-- 
g10 Code GmbH        -=- GnuPG.com -=-      AmtsGer. Wuppertal HRB 14459
Bergstr. 3a                                 Geschäftsführung Werner Koch
D-40699 Erkrath      https://gnupg.com      USt-Id DE215605608
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

to post comments

Koch: A New Future for GnuPG

Posted Jan 3, 2022 18:12 UTC (Mon) by cyperpunks (subscriber, #39406) [Link] (12 responses)

This seems a bit strange, GnuPG's /usr/bin/gpg is one of most bizarre software apps I have ever used.

There must be some other reason people donate money to GnuPG?

Koch: A New Future for GnuPG

Posted Jan 3, 2022 18:43 UTC (Mon) by vadim (subscriber, #35271) [Link] (10 responses)

It's very old school, and IMO that has greatly handicapped it. I think it could have been a far more successful project if it had modernized a bit.

The sensible modern way would be to have a GPG library, and the gpg command be an UI to that. This way the code could be reused for other purposes, and parts that are not necessary could just be avoided.

Instead of that, GPGME is a wrapper around the binary. Which means it still reads the user's configuration, uses ~/.gnupg, and so on. It makes it incredibly inconvenient if you'd like to create an application that's not completely connected to the user's normal identity. And calling gpg to decrypt messages incurs a significant performance impact, because of the initialization cost.

I remember long ago back when KDE had integrated GPG support I enthusiastically tried to use with some friends, but found it sucked. Any GPG message froze the UI for a couple seconds while GPG started up and decrypted every message one at a time. Rather than facilitating encryption it made it awfully inconvenient.

Until fairly recently doing anything with the GPG ecosystem was extremely annoying, because either you use /usr/bin/gpg, which sucks for many use cases, or you reimplement it, which is a lot of delicate work. Fortunately people are finally starting to write OpenPGP libraries, but of course that bypasses GPG entirely and doesn't benefit it.

Koch: A New Future for GnuPG

Posted Jan 3, 2022 20:20 UTC (Mon) by ballombe (subscriber, #9523) [Link] (4 responses)

Using a library means sensitive data end up in the process memory space and might be swapped out to disk, or leaked by other mean.

Koch: A New Future for GnuPG

Posted Jan 3, 2022 20:41 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

There is no reason a separate process has to behave like /usr/bin/gpg does (i.e. en/decrypt one message at a time, then exit). You could have a gpg-like daemon and send it commands over a pipe or (Unix domain) socket. You could even order it to zero and free all heap allocations, kill itself, and relaunch at the end of each session, or separate instances could be launched by each process which wants to use GPG functionality (just make sure they kill themselves after a reasonable amount of idle time has elapsed so they can't be orphaned for too long). Such a daemon could also sandbox itself, e.g. by running inside of some sort of heavily-restricted container.

Koch: A New Future for GnuPG

Posted Jan 4, 2022 17:30 UTC (Tue) by vadim (subscriber, #35271) [Link] (2 responses)

How does a process make that any better? If GPG is decrypting something for you, you end up with cleartext on the output, then it's your responsibility to deal with that properly.

I also don't see why a library couldn't do that. These days gpg runs as a normal user, because locking a small amount of memory is allowed by the kernel without any extra privileges. So a hypothetical libgpg could just do that.

Koch: A New Future for GnuPG

Posted Jan 4, 2022 17:44 UTC (Tue) by ballombe (subscriber, #9523) [Link]

At least the decrypted private keys, nonce used and anciliary secrets are not exposed.

Koch: A New Future for GnuPG

Posted Jan 4, 2022 18:07 UTC (Tue) by ibukanov (subscriber, #3942) [Link]

In-process library implementing crypto in software can be attacked via Spectre. So to protect against key and password leaks a separated process must be used with defenses against cross-process attacks exploiting hardware vulnerabilities that are not yet fixed.

Koch: A New Future for GnuPG

Posted Jan 4, 2022 17:25 UTC (Tue) by ballombe (subscriber, #9523) [Link] (2 responses)

> Instead of that, GPGME is a wrapper around the binary. Which means it still reads the user's configuration, uses ~/.gnupg, and so on. It makes it incredibly inconvenient if you'd like to create an application that's not completely connected to the user's normal identity.

Also gpgme cannot encrypt.
I solved this issue in Debian popularity-contest by creating a HOMEDIR before calling gpg and removing it afterward:

GPGHOME=`mktemp -d`
$GPG --batch --no-options --no-default-keyring --trust-model=always \
--homedir "$GPGHOME" --keyring $KEYRING --quiet \
--armor -o "$POPCONGPG" -r $POPCONKEY --encrypt "$POPCON"
rm -rf "$GPGHOME"

Koch: A New Future for GnuPG

Posted Jan 4, 2022 17:28 UTC (Tue) by vadim (subscriber, #35271) [Link]

Yup, that works, but that's a pain.

Koch: A New Future for GnuPG

Posted Jan 5, 2022 9:38 UTC (Wed) by ber (subscriber, #2142) [Link]

> Also gpgme cannot encrypt.

GPGME can encrypt:

https://gnupg.org/documentation/manuals/gpgme/Encrypt.html

Koch: A New Future for GnuPG

Posted Jan 5, 2022 9:32 UTC (Wed) by ber (subscriber, #2142) [Link] (1 responses)

When using GPGME to run gpg with one context, I could do more than 12 signatures a second in a simple server application in 2016 (see cold code https://github.com/Intevation/intelmq-mailgen/tree/master... here). So when using GPGME I believe speed is not really an issue for user facing applications.

The (very old) KMail integration blocked on some processes, which was also solved more than a decade ago (so long ago that I do not remember when) and was more an UI issue with network data always having the chance of being late and not being in control of the local application.

Using GPGME/gpg with a different identity works fine by setting a different GNUPGHOME environment variable in my experience.

The good part about GnuPG's technical structure from my point of view is that processes also separate concerns (like network access in dirmngr and private key operations in gpg-agent) and it makes it simpler to understand and reason about.

Koch: A New Future for GnuPG

Posted Jan 5, 2022 9:53 UTC (Wed) by ber (subscriber, #2142) [Link]

s/see cold code/see old code/
(sorry for the potentially confusing typo)

Koch: A New Future for GnuPG

Posted Jan 4, 2022 11:16 UTC (Tue) by zdzichu (subscriber, #17118) [Link]

I was going to comment that /usr/bin/gpg2 is supposed to have better UI. But I see that Fedora provides gpg as a symlink to gpg2 since F30 (about 3 years now). Maybe it's time to check if years-old experiences with gpg are still valid?

(I personally depend on google search and corporate step-by-step instruction if I need to do anything with GPG. Keybase at some point was trying to make crypto operation more intuitive, yet the development died after Zoom acquisition).

Koch: A New Future for GnuPG

Posted Jan 3, 2022 20:31 UTC (Mon) by karkhaz (subscriber, #99844) [Link] (3 responses)

> Although we support S/MIME, the majority of our customers decided in
> favor of the OpenPGP protocol, due to its higher flexibility and
> independence of a centralized public key infrastructure.

I assumed that a centralized PKI is exactly what enterprise/government customers would want to use, for ease of revocation/rotation/etc. It's quite surprising that these customers do see the benefit of OpenPGP, I wonder how the government makes it work (I don't suppose the civil servants are having keysigning parties...). This is very welcome news, anyway, congratulations!

Koch: A New Future for GnuPG

Posted Jan 3, 2022 20:44 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

It's easy to build your own centralized PKI on top of a decentralized system like OpenPGP. For example, designate one key as the CA-equivalent, tell everyone to mark that key as fully trusted (or more likely, have IT do it for them), and then use that key to sign all the other keys.

OTOH, building a decentralized system on top of a centralized system is substantially harder.

Koch: A New Future for GnuPG

Posted Jan 4, 2022 8:25 UTC (Tue) by taladar (subscriber, #68407) [Link]

GPG does support revocation certificates which allow the key owner to designate another key to generate a revocation certificate for it. That does allow a more central management of keys than would otherwise be possible.

Koch: A New Future for GnuPG

Posted Jan 4, 2022 8:53 UTC (Tue) by nilsmeyer (guest, #122604) [Link]

> I assumed that a centralized PKI is exactly what enterprise/government customers would want to use, for ease of revocation/rotation/etc. It's quite surprising that these customers do see the benefit of OpenPGP, I wonder how the government makes it work (I don't suppose the civil servants are having keysigning parties...).

Depends on the government agency, BSI uses it obviously, also some state data protection offices in Germany. There was an ill-fated attempt to build something for e-Mail (DE-Mail) that was a home grown solution, for healthcare there is something based on an x.509 PKI which is also not widely used, similarly there is something used by lawyers and courts (supposedly) also based on x.509 I believe. Fax and Mail still reign supreme in a lot of places.

The federally owned Bundesdruckerei (which also prints Euro notes for example) also offers S/MIME certificates, though barely anyone uses S/MIME.

It's not a comprehensive strategy - this is quite typical for Germany, what is unusual here is that the people in charge relied on an open standard instead of cooking up their own proprietary solution. I think it's quite an achievement actually to not only have a good technical solution in place but also to be able to convince a government agency to use it.

Koch: A New Future for GnuPG

Posted Jan 6, 2022 10:29 UTC (Thu) by nilsmeyer (guest, #122604) [Link] (3 responses)

Does it worry anyone that one of the major pieces of encryption infrastructure is funded by a government?

Koch: A New Future for GnuPG

Posted Jan 6, 2022 10:40 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

Massive quantities of cryptographic infrastructure we depend on was funded by governments in one way or another. I think the relevant question is whether we trust the individuals who implemented it or not.

Koch: A New Future for GnuPG

Posted Jan 7, 2022 5:54 UTC (Fri) by dvdeug (guest, #10998) [Link] (1 responses)

Do we trust the people making it? The German governmental groups funding it seem to be doing so for their own use. Shadowy forces working behind the scenes are scary; a bunch of government organizations buying a copy of a program, not so much. I'd also point out that it's not being funded by a government; it sounds like each government organization is making its own decisions about which tools they're using, within certain limits. I'd probably be more scared about AES, which was funded by the US government (cf. the whole Dual_EC_DRBG / NIST SP 800-90A escapade), and in any case, whether you see them or not, the NSA or similar organizations might be behind a cryptography project, and if they are, they're likely to try and stay hidden, especially if their intents are malign.

Trust is hard, but I don't see anything in this pattern that stands out as concerning; the biggest concern is that legitimate sources of money are the way to hide illegitimate sources of money, like from the NSA. (On the other hand, poverty makes someone easier to bribe.) I think it more likely the Germans are the ones getting backdoored here, instead of the one's backdooring, if there is a backdoor.

Koch: A New Future for GnuPG

Posted Jan 9, 2022 2:34 UTC (Sun) by JoeBuck (subscriber, #2330) [Link]

The German government isn't making it, they are just a customer. If you have suspicions you can audit the code.


Copyright © 2022, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds