blog: Add article about the OpenPGP.conf.
[gnupg-doc.git] / misc / blog.gnupg.org / 20160919-openpgp-conf.org
1 # OpenPGP.conf: A Success
2 #+STARTUP: showall
3 #+AUTHOR: Neal
4 #+DATE: September 19, 2016
5
6 On September 8th and 9th, the first [[https://www.gnupg.org/conf/program.html][OpenPGP.conf]] took place in Köln,
7 Germany.  The conference was organized by the [[German%20Unix%20User%20Group][German Unix User Group]]
8 (GUUG) and attracted over 50 participants from around the world.  The
9 program consisted of 18 highly technical talks.  Lunch and dinner were
10 provided at the venue, which resulted in lots of time to increase ties
11 between projects as well as exchange and develop ideas.
12
13 From the GnuPG project, Werner presented an introduction to the new
14 [[https://www.gnupg.org/blog/20160830-web-key-service.html][web key service (WKS) protocol]], which is being deployed by several
15 mail providers including [[https://posteo.de][Posteo]].  The basic problem that WKS addresses
16 is how to find someone's key.  Currently, most people just search the
17 key servers for keys matching the person's email address.  Although
18 this works reasonably well, the [[https://www.ncsc.nl/english/current-topics/factsheets/duplicate-pgp-keys.html][recent evil32 attack]] has reminded many
19 people that the keyservers provide no guarantees that a returned key
20 is controlled by the stated owner.  In WKS, people upload their keys
21 to their mail provider.  Since only the email account's owner can
22 change the association, this is guaranteed to not only be the right
23 key, but the user's preferred key.  Of course, users still need to
24 trust their mail provider to deliver the correct key.  But, we believe
25 this provides a significant improvement both in terms of security and
26 usability over the status quo.  Those requiring stronger guarantees
27 are still encouraged to either directly verify their communication
28 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
29 reported on Werner's presentation]].  Meskio from the LEAP project also
30 present [[https://meskio.net/openpgp.conf/#/][how LEAP is doing key discovery]].  Phillip Hallam-Baker
31 discussed [[https://www.gnupg.org/conf/2016/openpgp-2016-the-mathematical-mesh.pptx][key management in the Mesh]].  And, holger krekel discussed
32 [[https://www.gnupg.org/conf/2016/openpgp-2016-automatic-email-encryption-holger-krekel/index.html#/step-1][how to distribute keys inline]].
33
34 Justus discussed his proposal for [[https://www.gnupg.org/conf/2016/openpgp-2016-common-openpgp-testsuite.pdf][a common OpenPGP test suite]].  The
35 main problem that he observed in his recent work on the GPGME Python
36 bindings is that GPG, GPGME, and each of the GPGME bindings have their
37 own test suite that tests similar functionality to the other test
38 suites.  His idea is to merge the common parts by defining a simple
39 interface, and having each component just map the API to its own API.
40
41 Niibe presented his fully free cryptographic token, [[http://www.gniibe.org/pdf/openpgp-2016/gnuk-1_2.html][GnuK]] (pronounced:
42 ɡəˈnuːk), which he started developing in 2010.  The GnuK is special in
43 that it is the only cryptographic token that is based entirely on Free
44 Software, the entire hardware specification is open, and the parts are
45 relatively easy to buy.  This is motivated not only by ethical
46 concerns, but also security concerns: being able to assemble it
47 yourself makes it harder for an adversary to inject a trojan during
48 production.  Niibe also avoids specialized hardware.  This has less to
49 do with making it easier to get the components, and more to do with
50 security: getting documentation for secure chips, for instance,
51 requires signing an NDA and, due to their specialized nature, are more
52 likely to have a backdoor.  Instead, the GnuK uses a general purpose
53 CPU.  To protect the secret key material, it uses the flash ROM
54 protection feature.  There are currently discussions underway to
55 further increase the security of this by partially decrypting the
56 secret key material on the host with its much more capable CPU, which
57 would make a brute force attack significantly more expensive should
58 the key material be extracted.  The GnuK can currently be ordered
59 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]].
60
61 Andre discussed [[https://files.intevation.de/users/aheinecke/gpgme.pdf][how to use GPGME]].  The main takeaway is that although
62 GPGME's API is sometimes inconveniently low-level and some features
63 are missing, it is much easier to interact with GPG using GPGME than
64 to build another parser to parse GPG's ~--status-fd~ output.
65 Moreover, language bindings, such as Andre's bindings for Qt, can
66 significantly simplify working with GPGME.
67
68 Daniel reported on [[https://dkg.fifthhorseman.net/gnupg-in-debian-2016.svg][GnuPG in Debian]].  In particular, he discussed how
69 Debian is dealing with co-installing GnuPG 1.4 and GnuPG 2.1,
70 migration from 1.4 to 2.1, managing background processes, and system
71 integration.  He also discussed some issues that he has observed with
72 packages that use GnuPG.  In particular, their test suits often don't
73 test their use of GnuPG, because this requires so much effort.  He
74 indicated that one thing that would make life easier would be standard
75 pinentry driver programs for different languages.  He's since
76 submitted those for PHP, Perl, Python and Bash, and they will be part
77 of the next GnuPG release.
78
79 Another talk included a discussion of encrypted mailing list software
80 and the current state of Schleuder by Iif and paz.  Schleuder is
81 apparently the only encrypted mailing list software that currently
82 works (its also actively maintained).  Its design, however, requires
83 that the mailing list server be able to decrypt the messages in order
84 to reencrypt them to all of the subscribers.  The authors would like a
85 better solution, but, as they point out, there are ideas out there
86 (including my own proposal for [[http://hssl.cs.jhu.edu/~neal/encrypted-mailing-lists.pdf][practical encrypted mailing lists]]), but
87 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
88 Golem]].
89
90 One of my favorite talks was [[http://nskelsey.com/glbc-2016.pdf][Nick Skelsey's talk on GlobaLeaks]].  He
91 discussed typical leaking interactions, how their leaking platform
92 works, and the issues they face making the platform secure in the face
93 of non-technical users.
94
95 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
96 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
97 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]],
98 an overview of PEP, and an analysis of the keyserver data.
99
100 Given our very positive reactions from the participants and our own
101 positive impressions, we expect there to be a second edition of the
102 conference in the near future.