Logo: OpenPGP.conf

Cologne, September 8+9, 2016

Program

The program may be subject to changes, please watch for updates here and at @openpgp_conf.

Thursday

Time Title Speaker
09:30 – 10:15 A Simple Solution to Key Discovery (Slides) Werner Koch
10:15 – 11:00 Transparent Key Management at LEAP (Slides) meskio
11:00 – 11:30 Coffee break
11:30 – 12:15 The Mathematical Mesh: Management of Keys (Slides) Phillip Hallam-Baker
12:15 – 13:00 A stateless model for browser encryption in GlobaLeaks (Slides) Nick Skelsey
13:00 – 14:15 Lunch
14:15 – 14:30 Short talk: OpenPGP-encrypted email lists (Slides) ilf/paz
14:30 – 15:15 The State of three contracts from the German BSI (Slides) Bernhard Reiter
15:15 – 16:00 NEXTLEAP and Automatic E2E emails (slides) Holger Krekel
16:00 – 16:30 Coffee break
16:30 – 17:15 A few concerns regarding PGP, new directions (Slides) Stefan 'stf' Marsiske
17:15 – 18:00 History of OpenPGP (Slides) Lutz Donnerhacke
18:00 – 18:30 Key signing
18:30 – … Social event

Friday

Time Title Speaker
09:30 – 10:15 Automated use of GnuPG through GPGME (Slides) Andre Heinecke
10:15 – 11:00 Gnuk 1.2 (Slides) Yutaka Niibe
11:00 – 11:30 Coffee break
11:30 – 12:15 OpenKeychain UX decisions (Slides) Dominik S. and Vincent B.
12:15 – 13:00 Bypass Pinentry for good via […] (Slides) Seiya Kawashima
13:00 – 14:15 Lunch
14:15 – 14:30 Short talk: A proposal for a common OpenPGP test suite (Slides) Justus Winter
14:30 – 15:15 An update on the sks-keyservers.net services (Slides) Kristian Fiskerstrand
15:15 – 16:00 GnuPG in Debian Daniel Kahn Gillmor
16:00 – 16:30 Coffee break
16:30 – 16:45 Short talk: Inside and Beyond OpenPGP – Encryption for Everyone Volker Birk
16:45 – 17:00 Short talk: Analyzing Keyserver Data (Slides) Hanno Böck
17:00 – 18:00 Closing Event TBD

Abstracts

A Simple Solution to Key Discovery

Werner Koch

A major hassle with sending encrypted mails is to find the key matching the recipients mail address. A naïve method is to look for the key at a keyserver. In most cases this works surprisingly well. However, there is no guarantee that this key really matches the mail address — anyone can create a key and put an arbitrary mail address there. It is quite disturbing to receive a mail which you can't decrypt because it was encrypted to another key.

A solid solution is to associate the key with a mail address. The mail providers are the natural entities able to run a directory to lookup the keys for the addresses issued by them. An early approach to this is the PKA system, which uses the DNS to map mail addresses to fingerprints. However, it didn't get into real use.

Today the OpenPGP DANE method is used by a few mail providers. This method works by putting the key directly into the DNS and thus avoiding the need for keyservers. There are two problems with OpenPGP DANE: The system relies on DNSSEC which is not as robust as plain DNS and, worse, there is no easy way for software on end user boxes to take advantage of DNSSEC. The second drawback is the lack of confidentiality in DNSSEC lookups.

A simpler solution is to store the key under a well known URL and lookup it up via https. The properties of such a system are very similar to DANE but avoid the fragile DNSSEC setup and also provides some confidentiality of the key lookups. Such a Web based system is also easier to integrate into existing infrastructures; virtually all mail providers run a web server for the mail domain and serving static pages with the keys is a non-brainer. GnuPG implemented such a system under the name WKD in addition to DANE.

Note that both, DANE and WKD, are only used for key discovery. They are not meant to assert any validity of the key nor can they be used to detect BND-in-the-middle attacks. They merely solve the practical problem of first time key lookup and leave validation of the key to client based methods, for example TOFU. Advanced protocols, like CONIKS, can eventually be used on top to detect malicious mail providers who manipulate the answers of their key directories.

For practical deployment of DANE or WKD it is of paramount importance to have a way for the user to put their key into the directory. The new Web Key Service protocol provides a simple and elegant way to publish keys. It is designed to work only by mail so that it can be used by air-gapped clients or users who have only intermittent network connections. The requirement for a mail provider is to setup a dedicated mail address and route all mails to this address through a tool which runs the server side part of the protocol. Although it is possible for a user to run his part of the protocol by hand, it is desirable that mail clients are enhanced to have fully automated support for this protocol. Meanwhile, GnuPG comes with reference implementations for the server and client.

Werner Koch

Werner Koch, born 1961, is radio amateur since the late seventies and became interested in software development at about the same time. He worked on systems ranging from CP/M systems to mainframes, languages from assembler to Smalltalk and applications from drivers to financial analysis systems. He is widely known as the principal author of the GNU Privacy Guard.

Transparent Key Management at LEAP

meskio

At LEAP we improve email security with OpenPGP by encrypting messages on the users device without expecting any user interaction for key management. In order to achieve this we rely on additional services of the provider. This way we build on the decentralized nature of email and the power of communities to provide their own communication infrastructure.

Email providers form the largest open federated network for social identification and messaging. This is one of the reasons why we care about email but it's also part of why securing email is so hard. We have to deal with being backward compatible and the decentralized architecture and deployment.

In this talk we will introduce Bitmask - a client side application that encrypts emails before delivering them. We will also show how it's making use of the LEAP platform - a toolbox to setup and maintain providers based on best practices and extended to enable automatic key discovery.

Bitmask discovers keys by a variety of sources. We are compatible with the existing OpenPGP landscape by retrieving keys from email attachments, OpenPGP headers, OpenPGP signatures or the HKP pool. In addition we develop the NickNym protocol used by the providers to certify keys of it's users. As well as we explore new protocols like CONIKS, webkey-service or DANE. This way we introduce new methods of validation and thus reduce the need to trust the provider step by step.

We will explain the client server interaction and the logic we use for selecting keys to share our experiences and open a debate on how to do transparent key management, discuss security threats and usability issues.

meskio is a member of LEAP.

The Mathematical Mesh: Management of Keys

Phillip Hallam-Baker

As far as the conference program goes, the Mesh may be considered as a proposal to replace/augment the existing OpenPGP key server infrastructure with a new one that provides support for multiple PKI based applications and trust models.

In addition to making current PKI based applications usable, the Mesh management tools are also designed to enable the effective use of Matt Blaze's proxy re-encryption work, the relevance of which I will describe in a separate proposal.

The Mathematical Mesh is a user centric PKI that makes computers easier to use and also more secure. It can be used to simplify the use of existing public key applications (OpenPGP, S/MIME, SSH, TLS) and provides a platform that simplifies building of new applications.

The key concern for which the Mesh was designed to solve is the problem of managing multiple devices. When OpenPGP was first designed, virtually all Internet use was through a desktop machine. Today's users have phones, tablets and laptops. And even if they only use one device at a time. Portable devices have a much shorter life than static desktops. Many users have difficulty configuring their email accounts just once, this is surely one of the main reasons for the popularity of Web mail. Asking them to think about configuring cryptographic keys as well is hopeless.

The Mesh makes it easy for a user to transfer an email configuration from one machine to another and offers to automatically configure OpenPGP and S/MIME security at the same time. Rather than attempt to explain the advantages and disadvantages of either approach, the Mesh offers both.

Like DNS, the Mesh may be operated as a public or a private infrastructure or a combination of both. The public Mesh, known as the Cryptomesh is an untrusted Web service whose architecture may be loosely described as 'MIT keyserver meets blockchain'. Users access the Mesh through one (or more) portal providers of their own choice which they may change at any time.

Unlike in the CA model, portal providers are not required to be trusted or trustworthy. No private key information is ever exposed to the Mesh unless AES256 encrypted under keys under the sole control of the Mesh user.

A current OpenPGP keyserver could extend their services to offer Mesh services at no cost to the user. It is anticipated that commercial providers of portal services would operate a 'freemium' type model in which the basic Mesh service is provided for free but users have the option of upgrading their account to obtain security related services such as anti-malware, blocking of malicious Web sites, certificate issue, curated Web of Trust, etc.

Today, a security conscious user such as myself has to separately configure and maintain at least five separate trust infrastructures, OpenPGP, S/MIME, SSH, SSH for GIT, disk encryption. And the vast majority of the email they receive will arrive unencrypted anyway. The Mesh automates the management of those infrastructures and makes best practice the default rather than the rare exception.

The code for the Mesh itself and the tools used to build it are all open source and hosted on Sourceforge and GitHub. The specifications have been submitted as Internet drafts. As far as it can be known, there are no patent claims covering the design or implementation of the Mesh and there is clear prior art for the approach.

A stateless model for browser encryption in GlobaLeaks

Nick Skelsey

With GlobaLeaks now in widespread use among many successful initiatives, the Hermes Center intends to make it easier for people to stay safe while using the platform.

One of the largest barriers to using the platform safely is the use of PGP for the encryption and decryption of files submitted by whistleblowers to a server running GlobaLeaks. Most organizations that use the software opt out of PGP encryption due to the added complexity it places on the journalists handling encrypted material.

As a result we have produced a specification (and this presentation) with two related goals in mind: Improving the system’s usability for regular people and improving the security of the system for these users.

Nick Skelsey

Nick Skelsey is the lead developer at Whistleblowing Solutions, a core contributor to the GlobaLeaks project, and a member of HacDC.

OpenPGP for Android, Web and Windows, preparing for a formal evaluation and improving the user experience – three contracts from the German BSI

Bernhard Reiter

This talk will give an overview about three major contracts that the German BSI has award to the companies g10code and Intevation end of 2015. It will answer the questions:

"The goal of the Federal Office for Information Security (BSI) is to promote IT security in Germany." As part of this mission to promote more end-to-end security the BSI has more than 15 years long track-record of contracting improvements to GnuPG and related Free Software products like Kontact Mail or mutt. G10code and Intevation have an equally long track record performing the work together with KDAB.net and other companies. After a gap without major contracts, the BSI held three public tenders in 2015 with the following goals:

Gpg4all 2015:

Gpg4VSNfD 2015:

EasyGgp 2016:

More details can be found on https://wiki.gnupg.org/Gpg4win.

Bernhard Reiter

Bernhard Reiter is an entrepreneur and Free Software activist.

After his academic education as an Applied System Scientist at the University of Osnabrück Reiter earned an MSc degree in Geography at the University of Milwaukee. His research in the US was about phenology and climatic change. In 1999 Reiter co-founded the Free Software company Intevation.

Bernhard helped founding the charity associations FossGIS, FFII and Free Software Foundation Europe (FSFE). For FSFE he build up the German speaking team in the first decade and serves as member of the FSFE's general assembly.

Together with his company, Bernhard contributes to a number of Free Software initatives in technical and management roles. For example Bernhard lead the team developing the S/MIME email-solution for GnuPG and Kontact Mail in 2001. Between 2002 and 2010 Bernhard coordinated the Kolab groupware server and client developments, including the experimental mobile rich-client Kontact Touch. Since 2006 he is part of the Gpg4win-team.

NEXTLEAP and Automatic end-to-end encrypted emails

Holger Krekel

Email providers form the largest open federated network for social identification and messaging although there never was a shortage of doomsayers during this millennium. Providers and email technology developers can now play a pivotal role in both bringing about automatic end-to-end email encryption and bootstrapping and in anchoring other decentralized platforms. While there are some open research questions we are not alone in considering these goals within practical reach. Decentralization efforts also involve techno-social questions and perspectives such as how to empower communities to run their own privacy-preserving communication infrastructures. We sketch our planned open source and collaboration efforts regarding decentralized messaging. We place special emphasis on the role of providers who are to mediate public keys between users and on related social and technical accountability practises. Through this report and our prospective open source activities embedded within the EU-funded NEXTLEAP research project we wish to contribute to a privacy leap for email, more decentralized messaging and more community-operated infrastructures.

Holger Krekel is member of EU projekt NEXTLEAP.

A few concerns regarding PGP, new directions

Stefan 'stf' Marsiske

PGP is when used correctly a very powerful tool, however it is very difficult to use correctly. I'm not talking about johnny can't encrypt and about user experience, I'm more concerned about all the people already using PGP somehow and their OPSEC. PGP is a honourable veteran that was an essential weapon in the first cryptowars (see also the other talk). The design of the OpenPGP packet format in RFC4880 is rooted in the implementation done in the early and naive nineties. The threat model did not anticipate adversaries who can intercept all traffic and filter out cryptograms, and if neccessary can deploy commercially available malware to recover secret keys from barely protected consumer grade PCs. The way PGP is used and supported by graphical frontends does not encourage either anonymity of the senders (the packets contain lot's of information in plaintext). Just try running file(1) on a pgp encrypted non-armored file. The frontends also do not support perfect forward secrecy, non-repudiation, but allow for data mining the web-of-trust (ever had a lsign - key uploaded by a signer?). Refreshing keys often or using only symmetric keys is burdensome, as is using throw-keyids.

In the meantime a lot of PGP replacements have surfaced, some in javascript, but also some in more serious formats, some have good fixes for the above problems, some have good ideas or use-cases.

In this talk i'll try to cover the greatest concerns, some solutions, alternatives and hope to have a good discussion on the future of PGP.

Stefan 'stf' Marsiske gives workshops on radare2, embedded hw, lockpicking, soldering, gnuradio/sdr, reverse-engineering, crypto topics. Stf also does trainings on OPSEC for journalists and NGOs among others with the Tactical Technology Collective. Last year he scored in the top 10 of the Conference on Cryptographic Hardware and Embedded Systems Challenge. stf does a lot of other stuff too, he freelances as a pentester and operates one of the most comprehensive databases on EU policy-making. He played important roles in the founding of some central european hackerspaces, tech events and various NGOs. Long before all this he worked for Siemens doing reverse-engineering, unix development, telco security and innovation management.

History of OpenPGP

Lutz Donnerhacke

What happened about twenty years ago? PGP 2.6.3 was out and missed the opportunity to handle larger keys. But why? And why did the European folks fork a 2.6.3(i)n using a different library? With the rise of PGP 5, the source code was allowed to pass the export restrictions only in printed form. But after Hacking in Progress the code existed as compile-able digital files. Legally. We had the controversy of ADK and the stupid but with the random generator. And we still miss a standard document in order to "sell" PGP to governmental entities. Therefore an informal RFC was published and failed to meet the criteria. The second approach missed the IETF deadlines and was taken over by Europeans... Welcome to OpenPGP.

Automated use of GnuPG through GPGME

Andre Heinecke

Scripted or programmatic use of GnuPG is common and well supported in GnuPG. With command-fd and status-fd arguments GnuPG provides machine friendly output, tempting developers to use direct process calls, writing their own parsers for the output. While this might yield quick results, the devil is usually in the detail. Leading to subtle errors, especially if multiple Versions of GnuPG need to be supported.

To provide a stable interface for Programs across multiple versions, the GnuPG Project provides a reference Parser for GnuPG to be used as a Library, called "GnuPG Made Easy" (GPGME). GPGME allows developers to use GnuPG like a general C Library for OpenPGP (and CMS). Including key management, configuration and platform independent data source abstraction.

The talk will outline the advantages of using GPGME compared to direct process calls, showing examples how errors may be introduced when parsing GnuPG's output and how GPGME can help making development easier.

It will address the perceived complexity and some weaker points of GPGME, giving an outlook on the new "upstream" language Bindings (Python, C++, Qt) introduced with GpgME 1.7.0 and why these may help making GPGME more comfortable to use. Especially for Developers writing Programs in other Languages then C, again with some small examples. Encouraging the Audience to provide more bindings/wrappers or help extend the existing ones for their Problem.

Andre Heinecke is the current maintainer of Kleopatra, one of the most complex users of GPGME. As such he is also maintainer of the C++ Language binding for GPGME and the Qt Wrapper around it (QGpgME). Since 2013 he is also maintaining the Outlook Plugin for GnuPG (GpgOL) and Gpg4Win as the stable Windows distribution of GnuPG.

Gnuk 1.2

Yutaka Niibe

I'll talk about Gnuk 1.2, explaining its new features. My point is: how it is useful with new ECC of EdDSA and X25519.

Gnuk is a name of software, an implementation of USB cryptographic token for GnuPG. It is Free Software distributed under GPLv3+, and its development only requires Free Software.

"Gnuk Token" is a hardware device with Gnuk. With GnuPG, Gnuk Token is used for OpenPGP and/or OpenSSH. Typical use case is having a release key on Gnuk Token and only plugging in it to host when a signing for a release.

Gnuk supports OpenPGP card protocol, and it runs on STM32F103 processor. It holds private keys for GnuPG and does cryptographic computation using the keys.

The central ideas of Gnuk are:

Gnuk supports multiple boards of STM32F103, from STM32 Nucleo F103 to Olimex STM32-H103.

I also designed a reference hardware for Gnuk Token, that is, FST-01. FST-01's PCB design was done with KiCAD and it's under CC BY-SA 3.0. FST-01's spec is:

Gnuk version 1.2 supports ECC and RSA, while version 1.0 supported only RSA-2048. Specifically, it now supports:

Gnuk consists of following components:

Gnuk version 1.0 has been used among a limited community (FST-01 was sold about 700 pieces in three years). With new ECC and its GnuPG support, I wish it will be more popular among GnuPG community.

Yutaka NIIBE

Yutaka Niibe joined the development of GnuPG in 2011 in order to improve its smartcard support. Originally, he started Gnuk in September 2010 and realized that GnuPG's smartcard support was not that good, thus, he needed to. Now, he works for GnuPG/libgcrypt as a contractor. He works on smartcard support in GnuPG, ECC things in libgcrypt, and fixinig RSA, etc. For his free time he runs an NPO for Free Software in Japan named FSIJ. FSIJ is a small organization with no employees, composed by individual members and associate member companies. FSIJ is the copyright holder of Gnuk.

OpenKeychain UX Decisions

Dominik Schürmann and Vincent Breitmoser

In the last 4 years developing OpenKeychain, an OpenPGP implementation for Android, we made several unconventional UX decisions. While other implementations are still based on UX paradigms introduced in 1997 by PGP 5, we try to re-invent UX for a broader user base. Some of our decisions are subject to controversy in the OpenPGP community, in particular those of hiding information and complexity from the user, rather than giving them full control to make bad decisions. We hide Key IDs from the user, we don't use the words public and private, we never mention Key Signing or Keyservers, and we don't generate 8192 RSA keys. In this talk we give an overview over our different UX decisions, the reasoning behind them, and an overview of what is still work in progress or planned for future releases.

Dominik Schürmann

Dominik Schürmann received the M.Sc. degree in 2014. Since then he is a security researcher at the Institute of Operating Systems and Computer Networks at the TU Braunschweig, where he is pursuing a PhD degree. His research interests lie in the areas of security in Delay-Tolerant Networks, cryptographic protocols, and usable security. Since 2012 he is maintaining OpenKeychain, an OpenPGP implementation for Android.

Vincent Breitmoser …

Bypass Pinentry for good via GnuPG, GPGME and Pinentry

Seiya Kawashima

Passphrases play a crucial role to protect your secret keys. Within GnuPG ecosystem, Pinentry takes care of passphrase entry from the users. Pinentry kindly provides several ways to enter your passphrase in the GUI environemnt as well as command line environment. Digitally signing with your private key requires to type your passphrase every time you do such an operation unless your passphrase is cached in GnuPG. Even though luckily your passphrase is cached, you need to type your passphrase every time the cache is expired.

Bypassing Pinentry doesn't mean that disabling such a critical role of Pinentry but it's an automatic way to enter your passphrase when needed. This capability is practically useful. I'll present several potential cases. 1) Secure HTTP Cookie between the user and your web server. 2) Secure HTTP Cookie between your web servers such as a login server and a business logic server via HTTP Cookie through the user. 3) Automatic encryption, decryption, sign and verify without never asking a passphrase more than once. 4) Forward secrecy without human intervention.

You want your HTTP Cookie as secure as possible so that when it's altered, you would be able to notice it. To do so, your HTTP Cookie must be encrypted, signed and encoded by base64. When your Cookie returns from the user, you can verify that no unexpected modification has been done.

Sometimes it's necessary to pass information between one of your web servers to another via HTTP Cookie through the user. For example, the user must follow a certain procedure to use your service. First the user must request to a login server and then request to a business log server with signed and encrypted information from the login server via HTTP Cookie. In this case, the communication is done machine to machine so that signing, encryption, decryption and verification must be done automatically.

In the current software trend, the users expect not to work on any configuration before using software. They get used to tap on the screen, click a button and type some messages. Obviously GPG is too much. GPGMail on Mac OS is too much. Asking them a passphrase more than necessary is also too much. It would make them confused. As the result, they would simply choose not to use the software. Complicated configuration must be done automatically behind the scenes.

If your keys are changed frequently enough, it would be more secure because the keys that I used in the past are not valid in the future so that your privacy in the future will be protected via new keys. However the software must not expect the users to update their keys. This must be done without the users' help. The automatic Pinentry functionality makes it available to the software.

Forcing your passphrase to be valid in the cache would be a way to solve this situation but it's not elegant. Forcing you to type a passphrase every time it's expired in the cache is not ideal either. Ideally it's done behind the scenes so that novice users can use the technology without any knowledge. Thankfully, GnuPG ecosystem provides a way to solve this matter programmatically. In this talk, you will learn how to bypass Pinentry programmatically and elegantly so that passphrase entry can be done automatically.

Seiya Kawashima

Seiya Kawashima is an Application Programmer at the University of Chicago Radiology department. Free and open source software projects are important subjects for him not just as a user but a contributor or a little help who cares about the projects and the developers behind the projects. To express his appreciation to them, he spreads the word and submits bug fixes and new features to them. He has submitted a bug fix to Gnu libunistring and originally submitted Redis support to Java Hibernate OGM in the past.

An update on the sks-keyservers.net services

Kristian Fiskerstrand

sks-keyservers.net has been around since 2006 as a service providing, at its core, status information on keyservers and a DNS round-robin pool to make it convenient for OpenPGP users to access the keyserver network on an operational keyserver.

This talk will discuss some experiences operating the services and discuss new features related to new specifications such as Elliptic Curves (including but not limited to Ed25519 and Curve25519) and the experimental Tor support available at hkp://jirk5u4osbsr34t5.onion in addition to providing an overview of the other available pools such as the TLS enabled HKPS pool and the various geographical pools.

Kristian Fiskerstrand

Kristian Fiskerstrand is developing and running the sks-keyservers.net services and is one of the SKS (the keyserver software) upstream maintainers. He maintains GnuPG and g10 related packages in Gentoo Linux where he is also part of the Security team and a member of the Council.

GnuPG in Debian

Daniel Kahn Gillmor

I'll discuss the inclusion of GnuPG in the Debian operating system, including tradeoffs and decisions made around versioning, co-installation, backports, programmatic bindings, system integration, and support. I'll discuss implications for downstream distributions, and expectations around future versions and co-installability.