SoK: Why Johnny Can’t Fix PGP Standardization HARRY HALPIN, Inria Pretty Good Privacy (PGP) has long been the primary IETF standard for encrypting email, but suffers from widespread usability and security problems that have limited its adoption. As time has marched on, the underlying cryptographic protocol has fallen out of date insofar as PGP is unauthenticated on a per message basis and compresses before encryption. There have been an increasing number of attacks on the increasingly outdated primitives and complex clients used by the PGP eco-system. However, attempts to update the OpenPGP standard have failed at the IETF except for adding modern cryptographic primitives. Outside of official standardization, Autocrypt is a “bottom-up” community attempt to fix PGP, but still falls victim to attacks on PGP involving authentication. The core reason for the inability to “fix” PGP is the lack of a simple AEAD interface which in turn requires a decentralized public key infrastructure to work with email. Yet even if standards like MLS replace PGP, the deployment of a decentralized PKI remains an open issue. Additional Key Words and Phrases: email, PGP, standards, encryption ACM Reference Format: Harry Halpin. 2020. SoK: Why Johnny Can’t Fix PGP Standardization. 1, 1 (August 2020), 11 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn 1 INTRODUCTION Although it has been over two decades since its inception as an open standard, the OpenPGP (Pretty Good Privacy) standard is still widely deployed despite issues with usability, key management, and numerous attacks. The most recent process of standardization of OpenPGP at the IETF (Internet Engineering Task Force) started in 2015 and ended in November 2017, but did not attempt to address these underlying issues, instead focusing on upgrading the core primitives to use modern cryptographic primitives – a task which even the IETF standards process could not fully fix. After years of unsuccessful attempts to address PGP problems trying to make PGP more functional via new advanced server-side architecture [20] and Working Group activities at the IETF, a number of OpenPGP client developers created a new community effort called “Autocrypt” to address the underlying usability and key management issues. This effort also introduces new attacks and does not address some of the underlying cryptographic problems in PGP, problems that have been addressed in more modern protocol designs like Signal or IETF Message Layer Security (MLS). After decades of work, why can’t the OpenPGP standard be fixed? First, we start with the history of standardization of OpenPGP in Section 2. We consider the PGP protocol itself according to the modern understanding of cryptography in Section 3, inspecting whether some original design choices still make sense in terms of the security and privacy properties a user would expect. Then we move to summarizing arXiv:2008.06913v1 [cs.CR] 16 Aug 2020 the numerous attacks on PGP that the design and incomplete standardization of PGP opens up in Section 4. Note that there has been a large body of usability work on PGP, mostly with negative results and a large number of attacks Author’s address: Harry Halpin, [email protected], Inria, 2 Rue Simone Iff, Paris, France. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. © 2020 Association for Computing Machinery. Manuscript submitted to ACM Manuscript submitted to ACM 1 2 Harry Halpin based purely on usability problems, that we will only briefly overview as our primary focus in on standardization and protocol issues with PGP [21]. Lastly, we analyze the failed attempts to fix these issues via standardization in Section 5, including informal community-driven approaches like Autocrypt. Given the plethora of issues that exist with PGP, we analyze whether or not OpenPGP as a standard should continue at the IETF, given the underlying problem is a lack of a decentralized public key infrastructure in Section 6. 2 STANDARDIZATION OF OPENPGP Pretty Good Privacy (PGP) is a well-known cryptographic protocol for using asymmetric cryptography to provision confidentiality to the masses. At the very time when the U.S. government was attempting to restrict the spread of “strong” encryption in what was known as the first “Crypto Wars,” the release of PGP’s open source code made it seemingly impossible to control the spread of tools for encryption [19]. The original scheme of PGP (“PGP 1.0”) was written by Philip Zimmerman, a peace activist, with its source code published on the Internet in 1991, first to a ISP called PeaceNet and then to Usenet. The goal was encrypting email, based on the plaintext Simple Mail Transfer Protocol (SMTP). As PGP depended on RSA primitives for public key encryption and signatures, PGP attracted the attention of the company RSA Security Inc., which had patented the original RSA algorithms – and even the United States government, which attempted to prosecute Zimmerman on breaking an encryption ban on “strong” cryptography by posting the source code internationally. Turning PGP into a standard at the IETF both helped prevent a single company from preventing its further spread via patent claims by providing a version that did not use RSA (thus the standard was called “OpenPGP”) and served as a strategic bulwark against further repression by weaving encryption into the open standards that defined the Internet itself.1 Although Ron Rivest and others at MIT convinced RSA Security Inc. not to pursue any further patent actions and the United States government dropped their court case against Zimmerman in January 1996, Phil Zimmerman submitted an informational (non-standard) RFC 1991 called “PGP Message Exchange Formats”2 to the IETF in August 1996, describing various minor versions of “PGP 2.0.” Importantly, this document divided the actual encrypted message into separate variable length “packets,” where each packet contained a header specifying its type (“tag”) and a packet body. These packets may contain encrypted keys, encrypted messages, signatures, certificates, and so on. RFC 1991 featured not only RSA, but also the patented IDEA algorithm3 and MD5 for hash functions.4 In order to harmonize with email standards, OpenPGP was made compatible with Multi-purpose Internet Mail Extensions (MIME)5 via IETF RFC 2015 “MIME Security with Pretty Good Privacy.”6 While OpenPGP-encrypted email was originally delivered simply as encrypted and signed plaintext in the OpenPGP Message format using standard SMTP, email best practices mandated some parts be delivered as multi-part MIME messages. In MIME messages, the content of the message is divided between different MIME parts, so that the encrypted body is delivered as a separate MIME part than the signature or attached keys. 1Much of the history of PGP and its standardization has been summarized from various mailing lists on ietf.org. 2https://tools.ietf.org/html/rfc1991 3https://register.epo.org/application?number=EP91908542 4Although these may seem questionable choices today given various known attacks on IDEA and MD5, it should be rememberedthat cryptography was generally not standardized at the time with both IDEA and MD5 considered secure. Zimmerman replaced his own broken cipher Bass-o-matic in PGP 1.0 with IDEA after the release of PGP. 5The IETF standard for sending messages with multiple components (such as a digital signature and a body as specified in IETF RFC 1521 https://tools.ietf.org/html/rfc1521 6https://tools.ietf.org/html/rfc2015 Manuscript submitted to ACM SoK: Why Johnny Can’t Fix PGP Standardization 3 The year after the original submission by Zimmerman, the original IETF OpenPGP Working Group opened in Sep- tember 1997. Within a year the OpenPGP produced IETF RFC 2440 in 19987 on “the OpenPGP Message Format.”8 This document also described certificates, identities, and in more detail the operations necessary for signing, encryp- tion, and decryption of data with OpenPGP. In particular, it expanded the ciphersuite choice by making mandatory the patent-free El-Gamal for asymmetric encryption, SHA-1 for hash functions, DSA for signatures, and 3DES for symmetric encryption. It also ended up recommending CAST-128, with an infamous 128 bit key and the weak S2K (String-to-Key) KDF for converting plaintext passwords to keys. MIME usage was also updated in 2001 as RFC 3156 “MIME Security with Open PGP.”9 The OpenPGP Working Group was then closed. Due to advances in cryptography and attacks detailed in Section 4, the IETF reopened the OpenPGP Working Group in May 2003. Four years later RFC 2440 was updated by the Working Group as IETF RFC 4880 in 2007.10 The primary change was the addition of PKCS1-v1_5 encoding and the optional use of a modified version of AES-CFB mode for symmetric encryption with the addition of Modification Detection Codes (MDCs) to provide a limited form of integrity to symmetric encryption. In brief, an MDC attempts to alert the recipient if their message has been corrupted by attaching an encrypted SHA-1 hash of the plaintext as the last packet in a message. Also, MD5 was deprecated and IDEA made optional. The OpenPGP Working Group was again closed in 2008, but the mailing list continued to be somewhat active, with PGP able to work with most major operating systems, including eventually Microsoft Outlook, Apple Mail, Mozilla Thunderbird, and others.