blog: Add article about the OpenPGP.conf.
authorNeal H. Walfield <neal@gnu.org>
Mon, 19 Sep 2016 12:14:42 +0000 (14:14 +0200)
committerNeal H. Walfield <neal@gnu.org>
Mon, 19 Sep 2016 12:25:00 +0000 (14:25 +0200)
misc/blog.gnupg.org/20160919-openpgp-conf.org [new file with mode: 0644]

diff --git a/misc/blog.gnupg.org/20160919-openpgp-conf.org b/misc/blog.gnupg.org/20160919-openpgp-conf.org
new file mode 100644 (file)
index 0000000..198c2b2
--- /dev/null
@@ -0,0 +1,102 @@
+# OpenPGP.conf: A Success
+#+STARTUP: showall
+#+AUTHOR: Neal
+#+DATE: September 19, 2016
+
+On September 8th and 9th, the first [[https://www.gnupg.org/conf/program.html][OpenPGP.conf]] took place in Köln,
+Germany.  The conference was organized by the [[German%20Unix%20User%20Group][German Unix User Group]]
+(GUUG) and attracted over 50 participants from around the world.  The
+program consisted of 18 highly technical talks.  Lunch and dinner were
+provided at the venue, which resulted in lots of time to increase ties
+between projects as well as exchange and develop ideas.
+
+From the GnuPG project, Werner presented an introduction to the new
+[[https://www.gnupg.org/blog/20160830-web-key-service.html][web key service (WKS) protocol]], which is being deployed by several
+mail providers including [[https://posteo.de][Posteo]].  The basic problem that WKS addresses
+is how to find someone's key.  Currently, most people just search the
+key servers for keys matching the person's email address.  Although
+this works reasonably well, the [[https://www.ncsc.nl/english/current-topics/factsheets/duplicate-pgp-keys.html][recent evil32 attack]] has reminded many
+people that the keyservers provide no guarantees that a returned key
+is controlled by the stated owner.  In WKS, people upload their keys
+to their mail provider.  Since only the email account's owner can
+change the association, this is guaranteed to not only be the right
+key, but the user's preferred key.  Of course, users still need to
+trust their mail provider to deliver the correct key.  But, we believe
+this provides a significant improvement both in terms of security and
+usability over the status quo.  Those requiring stronger guarantees
+are still encouraged to either directly verify their communication
+partner's key or use the web of trust.  The German news site [[http://www.golem.de/news/web-key-service-openpgp-schluessel-ueber-https-verteilen-1609-123194.html][Golem
+reported on Werner's presentation]].  Meskio from the LEAP project also
+present [[https://meskio.net/openpgp.conf/#/][how LEAP is doing key discovery]].  Phillip Hallam-Baker
+discussed [[https://www.gnupg.org/conf/2016/openpgp-2016-the-mathematical-mesh.pptx][key management in the Mesh]].  And, holger krekel discussed
+[[https://www.gnupg.org/conf/2016/openpgp-2016-automatic-email-encryption-holger-krekel/index.html#/step-1][how to distribute keys inline]].
+
+Justus discussed his proposal for [[https://www.gnupg.org/conf/2016/openpgp-2016-common-openpgp-testsuite.pdf][a common OpenPGP test suite]].  The
+main problem that he observed in his recent work on the GPGME Python
+bindings is that GPG, GPGME, and each of the GPGME bindings have their
+own test suite that tests similar functionality to the other test
+suites.  His idea is to merge the common parts by defining a simple
+interface, and having each component just map the API to its own API.
+
+Niibe presented his fully free cryptographic token, [[http://www.gniibe.org/pdf/openpgp-2016/gnuk-1_2.html][GnuK]] (pronounced:
+ɡəˈnuːk), which he started developing in 2010.  The GnuK is special in
+that it is the only cryptographic token that is based entirely on Free
+Software, the entire hardware specification is open, and the parts are
+relatively easy to buy.  This is motivated not only by ethical
+concerns, but also security concerns: being able to assemble it
+yourself makes it harder for an adversary to inject a trojan during
+production.  Niibe also avoids specialized hardware.  This has less to
+do with making it easier to get the components, and more to do with
+security: getting documentation for secure chips, for instance,
+requires signing an NDA and, due to their specialized nature, are more
+likely to have a backdoor.  Instead, the GnuK uses a general purpose
+CPU.  To protect the secret key material, it uses the flash ROM
+protection feature.  There are currently discussions underway to
+further increase the security of this by partially decrypting the
+secret key material on the host with its much more capable CPU, which
+would make a brute force attack significantly more expensive should
+the key material be extracted.  The GnuK can currently be ordered
+either from [[https://www.seeedstudio.com/FST-01-without-Enclosure-p-1276.html][seeed]] or the [[https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator][FSF]].
+
+Andre discussed [[https://files.intevation.de/users/aheinecke/gpgme.pdf][how to use GPGME]].  The main takeaway is that although
+GPGME's API is sometimes inconveniently low-level and some features
+are missing, it is much easier to interact with GPG using GPGME than
+to build another parser to parse GPG's ~--status-fd~ output.
+Moreover, language bindings, such as Andre's bindings for Qt, can
+significantly simplify working with GPGME.
+
+Daniel reported on [[https://dkg.fifthhorseman.net/gnupg-in-debian-2016.svg][GnuPG in Debian]].  In particular, he discussed how
+Debian is dealing with co-installing GnuPG 1.4 and GnuPG 2.1,
+migration from 1.4 to 2.1, managing background processes, and system
+integration.  He also discussed some issues that he has observed with
+packages that use GnuPG.  In particular, their test suits often don't
+test their use of GnuPG, because this requires so much effort.  He
+indicated that one thing that would make life easier would be standard
+pinentry driver programs for different languages.  He's since
+submitted those for PHP, Perl, Python and Bash, and they will be part
+of the next GnuPG release.
+
+Another talk included a discussion of encrypted mailing list software
+and the current state of Schleuder by Iif and paz.  Schleuder is
+apparently the only encrypted mailing list software that currently
+works (its also actively maintained).  Its design, however, requires
+that the mailing list server be able to decrypt the messages in order
+to reencrypt them to all of the subscribers.  The authors would like a
+better solution, but, as they point out, there are ideas out there
+(including my own proposal for [[http://hssl.cs.jhu.edu/~neal/encrypted-mailing-lists.pdf][practical encrypted mailing lists]]), but
+none of them work today.  This presentation was also [[http://www.golem.de/news/schleuder-wie-verschluesselt-man-eine-mailingliste-1609-123206.html][reported on by
+Golem]].
+
+One of my favorite talks was [[http://nskelsey.com/glbc-2016.pdf][Nick Skelsey's talk on GlobaLeaks]].  He
+discussed typical leaking interactions, how their leaking platform
+works, and the issues they face making the platform secure in the face
+of non-technical users.
+
+Other talks included an overview of some [[http://www.intevation.de/~bernhard/presentations/201609-openpgpconf/20160908-3bsi-contracts.pdf][work that the German BSI has
+contracted]], [[https://www.gnupg.org/conf/2016/openpgp-2016-a-few-concerns.pdf][an analysis of OpenPGP]], [[http://altlasten.lutz.donnerhacke.de/mitarb/lutz/vortrag/openpgp-history.pdf][a history of OpenPGP]], [[https://www.gnupg.org/conf/2016/openpgp-2016-openkeychain.pdf][OpenKeychain
+UX decisions]], [[https://www.gnupg.org/conf/2016/openpgp-2016-bypass-pinentry.pdf][how to bypass pinentry]], [[https://sks-keyservers.net/files/2016-09_OpenPGP-Conf-sks-keyservers.pdf][an update on the sks keyservers]],
+an overview of PEP, and an analysis of the keyserver data.
+
+Given our very positive reactions from the participants and our own
+positive impressions, we expect there to be a second edition of the
+conference in the near future.