Internet DRAFT - draft-ford-openpgp-format

draft-ford-openpgp-format







OpenPGP Working Group                                            B. Ford
Internet-Draft                                                      EPFL
Intended status: Standards Track                        October 19, 2015
Expires: April 21, 2016


                 Modernizing the OpenPGP Message Format
                      draft-ford-openpgp-format-00

Abstract

   This draft proposes and solicits discussion on methods of modernizing
   OpenPGP's encrypted message format to support more state-of-the-art
   authenticated encryption schemes, and optionally to protect format
   metadata as well as data via metadata encryption and judicious
   padding.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 21, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Ford                     Expires April 21, 2016                 [Page 1]

Internet-Draft           OpenPGP Message Format             October 2015


Table of Contents

   1.  Overview and Rationale  . . . . . . . . . . . . . . . . . . .   2
   2.  Adopting Authenticated Encryption Schemes . . . . . . . . . .   2
     2.1.  AEAD Protected Data Packet  . . . . . . . . . . . . . . .   3
     2.2.  Concrete AEAD Schemes . . . . . . . . . . . . . . . . . .   4
       2.2.1.  AES-GCM . . . . . . . . . . . . . . . . . . . . . . .   4
       2.2.2.  ChaCha20-Poly1305 . . . . . . . . . . . . . . . . . .   4
       2.2.3.  Keccak-based sponge scheme  . . . . . . . . . . . . .   5
       2.2.4.  Future: CAESAR competition winner . . . . . . . . . .   5
     2.3.  Metadata Leakage-Hardening the OpenPGP Format . . . . . .   5
       2.3.1.  Encrypting file format metadata . . . . . . . . . . .   6
       2.3.2.  Intelligent padding to minimize size-based leakage  .   7
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     4.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Overview and Rationale

   The current OpenPGP message format [RFC4880] has evolved periodically
   to support new cryptographic algorithms, but its structure embodies
   assumptions and imposes limitations that are overdue for
   reconsideration and modernization based on today's cryptographic
   best-practices and evolved threat models.  This draft proposes, as a
   starting point for discussion, several of these issues and potential
   approaches to modernizing the OpenPGP format to address them.

2.  Adopting Authenticated Encryption Schemes

   The OpenPGP format currently handles symmetric-key encryption and
   integrity services as separate, orthogonal mechanisms.  It is now
   widely accepted in the cryptographic community, however, that it is
   often advantageous to both performance and security to roll
   symmetric-key encryption and identity protection together into a
   single cryptographic abstraction, now commonly known as Authenticated
   Encryption with Additional Data or AEAD.  An increasingly rich body
   of AEAD schemes is now available that considerably reduce computation
   cost with respect to the traditional approach of applying encryption
   and hash-based identity protection as separate, orthogonal steps.

   Enhancing the OpenPGP format to support AEAD schemes will involve two
   main updates to the OpenPGP format specification: (1) defining a
   suitable AEAD-based alternative encoding for the current
   Symmetrically Encrypted Integrity Protected Data packet (Tag 18,
   section 5.13 of [RFC4880]); and (2) defining at least one concrete
   AEAD scheme usable in this new data Encrypted Data packet format.



Ford                     Expires April 21, 2016                 [Page 2]

Internet-Draft           OpenPGP Message Format             October 2015


   The sections below first propose a first-cut AEAD Data Packet format,
   then briefly point out several possible AEAD algorithms for
   consideration.

2.1.  AEAD Protected Data Packet

   The proposed AEAD Protected Data packet (tentatively Tag 20) contains
   data that is both encrypted and integrity-protected by a single AEAD
   algorithm, defined by the selected symmetric-key cipher.  Symmetric-
   key AEAD algorithms occupy the same identifier space as traditional
   symmetric ciphers such as IDEA and Twofish (listed in section 9.2 of
   [RFC4880]), but require the use of AEAD Protected Data packets
   exclusively.  That is, an OpenPGP message whose selected symmetric-
   key algorithm is an AEAD algorithm MUST use the AEAD Protected Data
   packet, while a message whose selected symmetric-key algorithm is not
   an AEAD algorithm MUST NOT use the AEAD Protected Data packet.

   AEAD algorithms in general take as inputs: (1) a symmetric secret
   key, (2) a nonce or IV whose presence and size depends on the
   algorithm, (3) a variable-length body to be encrypted and identity
   protected, and (4) an "additional data" field to be identity
   protected but not encrypted (often as header and/or trailer
   metadata).  The AEAD algorithm produces: (1) a ciphertext containing
   the encrypted content of the variable-length body, and (2) a fixed-
   length authenticator protecting the integrity of both the encrypted
   body and the additional data.

   In OpenPGP's specific use of an AEAD algorithm, the symmetric secret
   key input is defined by the OpenPGP Session Key as conveyed in the
   message's public-key and/or symmetric-key ESK packets.

   In the context of OpenPGP, there is no clear need for the "additional
   data" feature of AEAD schemes (in contrast with the uses of AEAD
   schemes to encrypt packets or datagrams), so we tentatively propose
   that the "additional data" field always be considered to be empty (0
   bytes) in the context of OpenPGP.  (DISCUSS: are we missing potential
   uses of this that might warrant inclusion of some field or extension
   allowing the AD part to be nonempty?)

   The AEAD Protected Data packet in an OpenPGP message contains the
   following octet sequences, directly concatenated: (1) the nonce or IV
   required by the AEAD algorithm, if any, encoded as a fixed-length
   header whose size is determined by the symmetric-key scheme; (2) the
   variable-length ciphertext representing the AEAD-encrypted body; and
   (3) the authenticator, as a fixed-length trailer whose size is
   determined by the symmetric-key scheme.  Note that symmetric-key AEAD
   schemes MAY expand the size of the body during encryption (e.g., due
   to internal metadata and/or padding), but if so, MUST enable the



Ford                     Expires April 21, 2016                 [Page 3]

Internet-Draft           OpenPGP Message Format             October 2015


   decrypting side to determine the true size of the original variable-
   length cleartext (e.g., by including any necessarily metadata within
   the encrypted ciphertext to indicate how much padding was added to
   the plaintext before encryption).

   When an AEAD symmetric-key cipher is used, the Modification Detection
   Code Packet (Tag 19) MUST NOT be used.  (DISCUSS: can anyone identify
   any benefit to placing the authenticator in a separate packet?  The
   justification for the current proposal is that in all the AEAD
   schemes I'm aware of the authenticator is fixed-size and thus has no
   need for additional size metadata.)

   DISCUSS: in nonce-based AEAD schemes, the nonce is technically not
   needed (or can be taken to be all 0's) if the symmetric-key is used
   only once, which is likely to be at least the common case for OpenPGP
   where the AEAD symmetric key is the one-time session key.  Thus, we
   could save the size of the nonce provided there is only ever at most
   one encrypted data packet.  The downside is the risk of a security
   disaster if any implementation ever (incorrectly) produces multiple
   AEAD Protected Data packets using the same key.

2.2.  Concrete AEAD Schemes

   The proposed AEAD enhancement will require the definition of at least
   one and perhaps multiple concrete AEAD schemes to be specified for
   use with OpenPGP.  We propose the following choices as starting
   points for discussion, deferring for now the instantiation details of
   each:

2.2.1.  AES-GCM

   The AES cipher operated in Galois-Counter Mode (GCM) [GCM] has become
   a well-accepted AEAD scheme used in other Internet standards
   [RFC5288][RFC4106] and has no known serious cryptographic weaknesses.
   Thus, AES-GCM is likely to be a reasonable choice for inclusion in an
   AEAD extension to OpenPGP, even if it is does not necessarily
   represent the current state-of-the-art in performance or security.

2.2.2.  ChaCha20-Poly1305

   The ChaCha20 stream cipher used with the Poly1305 authenticator
   [RFC7539] has gained considerable traction as a practical alternative
   to AES-GCM providing high performance especially in tuned software
   implementations, believed to offer security comparable to or better
   than AES-GCM, and based on contrasting cryptographic foundations.






Ford                     Expires April 21, 2016                 [Page 4]

Internet-Draft           OpenPGP Message Format             October 2015


2.2.3.  Keccak-based sponge scheme

   The Keccak sponge function forms the cryptographic core of the
   recently-standardized SHA-3 family of hash algorithms [SHA3].  As a
   sponge construction, Keccak offers an attractive basis for AEAD
   schemes because the sponge construction can currently "absorb" bits
   for integrity protection and "produce" pseudorandom bits for
   encryption, while adding no significant overhead above the cost of
   one or the other.  As SHA-3 has received substantial public attention
   and cryptanalysis, it represents a safe choice from a security
   perspective, and is based on substantially different cryptographic
   foundations from either of the above choices, offering further
   diversity.  A particular Keccak-based AEAD construction would need to
   be selected, such as the well-known MonkeyDuplex [MONKEY] among other
   reasonable choices.

2.2.4.  Future: CAESAR competition winner

   The CAESAR competition [CAESAR] is in the process of selecting a new
   AEAD scheme for public recognition.  The winner will not
   automatically become a formal standard per se but may become a "de
   facto" standard due to the extensive public cryptanalysis all the
   competitors are currently undergoing, and as such will represent an
   obvious potential choice for future standardization in an AEAD-
   enhanced OpenPGP message format.

2.3.  Metadata Leakage-Hardening the OpenPGP Format

   The current OpenPGP format encodes a considerable amount of metadata
   about an OpenPGP-encrypted encrypted file "in the clear": for
   example, (1) the fact that it is an OpenPGP-encrypted file, (2)
   exactly which public-key and/or symmetric-key algorithms the file is
   encrypted with, (3) whether or not the file can be decrypted with a
   passphrase, (4) whether or not the file can be decrypted with a
   public/private keypair, and if so how many distinct keypairs can be
   used to decrypt the file, and (5) the length of the encrypted
   message.  See [METADATA] for an illustration of this metadata.

   While this unencrypted metadata was not thought to be privacy-
   sensitive when the OpenPGP format was first designed, the evolution
   of today's threats have called this assumption into question.  For
   example, the very existence on a hard drive of a file that is readily
   identifiable as OpenPGP-encrypted can arouse suspicion and has been
   known to lead airport, border-control, and other authorities of some
   countries to demand passwords or decryption keys under threat of
   incarceration even if it is not clear that the holder of the device
   is in possession of the necessary decryption keys.  Furthermore, as
   the state-of-the-art in cryptanalysis and brute-force attacks



Ford                     Expires April 21, 2016                 [Page 5]

Internet-Draft           OpenPGP Message Format             October 2015


   gradually overtakes the security of older cryptographic schemes, the
   existence of a cryptographic scheme identifier in cleartext
   effectively acts as a "crack me!" flag, making it unnecessarily easy
   for an attacker to invest computational resources selectively into
   cracking ciphertexts known to use weak cryptographic schemes, while
   avoiding wasting compute resources attempting to crack ciphertexts
   encrypted under stronger schemes.  The number of distinct public keys
   that can decrypt a file can serve to identify the group of people for
   which the file was encrypted.  Finally, even the file's length can
   represent sensitive, possibly incriminating information especially in
   known-plaintext situations, e.g., when an attacker suspects but
   cannot otherwise prove that an OpenPGP file on a suspected
   whistleblower's or dissident's hard disk is an encryption of a
   particular document.

   We therefore suggest for discussion two possible measures for the
   further evolution of the OpenPGP format to reduce this metadata
   leakage: encrypted metadata, and optional length padding.

2.3.1.  Encrypting file format metadata

   OpenPGP's current format makes the decryption process "easy" in the
   sense that it is immediately clear to the decryptor which
   cryptographic algorithms should be used to decrypt the file, at the
   cost of the metadata leaks above.  It is readily feasible to define a
   new OpenPGP format in which no metadata is left unencrypted, leaving
   the encrypted file's contents appearing to be a "Uniformly Random
   Blob" or URB.

   The obvious challenge such a format change presents is that the
   decryptor will not know a priori which encryption scheme(s) were used
   to encrypt a particular file, and hence would simply have to try in
   turn each of the schemes it supports.  For files protected only by a
   single passphrase, implementing full metadata protection in this
   fashion is straightforward.  While it may seem likely to incur
   significant cost, note that the decryptor need not attempt to decrypt
   the entire file using each scheme, but only a short header portion,
   before either successfully identifying the scheme in use (or giving
   up if the passphrase is wrong and/or the scheme is unsupported).

   A fully-encrypted-metadata format is more challenging in the general
   case of files encrypted using a combination of one or more
   passphrases and/or one or more public keypairs, but still readily
   feasible, so as to require the decryptor to perform only one
   expensive "trial" public-key operation per scheme (not per key) on a
   file encrypted with any number of symmetric and/or public keys.
   Details will be expanded on if the WG decides this to be a direction
   potentially worth pursuing.



Ford                     Expires April 21, 2016                 [Page 6]

Internet-Draft           OpenPGP Message Format             October 2015


2.3.2.  Intelligent padding to minimize size-based leakage

   Even if the directly-encoded metadata of an OpenPGP file is encrypted
   as discussed above, the file's mere length can still represent
   significant leakage, likely immediately revealing the existence of a
   known plaintext on a hard drive for example.  The only "perfect"
   solution from a security perspective - is to pad all encrypted files
   to a common length - is obviously impractical from an efficiency
   perspective.

   A second, more conceivable but still costly choice would be to pad
   files to (for example) the next power-of-two in size.  This reduces
   the maximum possible information leakage from an N-byte file from
   O(log N) to O(log log N), but the up-to-100% expansion factor (50%
   expansion on average) is significant and likely to be a considerable
   deterrent against use.

   A better choice would be to use a slightly more sophisticated padding
   scheme, which pads any encrypted file into "size buckets" chosen to
   limit maximum information leakage to O(log log N) - asymptotically
   equivalent to the simple next-power-of-two scheme - while ensuring
   that no file incurs more than about a 10% expansion and large files
   incur progressively smaller expansion factors (e.g., no more than 3%
   for files 1MB or larger).  Details of this scheme will be expanded if
   the WG deems this direction potentially worth pursuing.

   In combination with the above encrypted-metadata techniques, the
   resulting benefit is that (new) OpenPGP-encrypted messages or files
   would be substantially more "anonymous" than they are now, at least
   within the set of plaintexts whose ciphertext lengths fall into one
   of these padded "size buckets."  Furthermore, since the padding
   scheme need not be specific to OpenPGP, the result would be that
   metadata-protected, encrypted files produced by any application
   designed to use the same padding scheme would produce objects
   cryptogrphically indistinguishable from others in the same "size
   bucket" across every application supporting a compatible padding
   scheme.  Thus, the resulting "Padded Uniform Random Blobs" or PURBs
   could eventually provide metadata protection and some level of
   "encrypted file anonymity" not only within the context of one
   application (e.g., OpenPGP) but across different applications that
   produce PURBs in quite different ways.

3.  Security Considerations

   No new security considerations (beyond those that already apply to
   OpenPGP's existing message format) have been identified so far, but
   likely will be.




Ford                     Expires April 21, 2016                 [Page 7]

Internet-Draft           OpenPGP Message Format             October 2015


4.  References

4.1.  Normative References

   [GCM]      Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: Galois/Counter Mode (GCM) and GMAC", NIST
              Special Publication 800-38D, November 2007,
              <http://csrc.nist.gov/publications/nistpubs/800-38D/
              SP-800-38D.pdf>.

   [MONKEY]   Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche,
              "Permutation-based encryption, authentication and
              authenticated encryption", Directions in Authenticated
              Ciphers 2012, August 2015,
              <http://keccak.noekeon.org/KeccakDIAC2012.pdf>.

   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
              (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
              4106, DOI 10.17487/RFC4106, June 2005,
              <http://www.rfc-editor.org/info/rfc4106>.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/
              RFC4880, November 2007,
              <http://www.rfc-editor.org/info/rfc4880>.

   [RFC5288]  Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
              Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI
              10.17487/RFC5288, August 2008,
              <http://www.rfc-editor.org/info/rfc5288>.

   [RFC7539]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
              <http://www.rfc-editor.org/info/rfc7539>.

4.2.  Informative References

   [METADATA]
              Underwood, M., "The information leaked from a gpg
              encrypted file.", October 2015,
              <https://drive.google.com/file/
              d/0BwK1bcoczINteWVwVFN5UWNORW8/view?usp=sharing>.

Author's Address







Ford                     Expires April 21, 2016                 [Page 8]

Internet-Draft           OpenPGP Message Format             October 2015


   Bryan Ford
   EPFL
   BC 210, Station 14
   Lausanne  CH-1015
   Switzerland

   Phone: +41 21 693 28 73
   Email: bryan.ford@epfl.ch











































Ford                     Expires April 21, 2016                 [Page 9]