[openpgp] Message padding in OpenPGP
Justus Winter <justuswinter@gmail.com> Tue, 24 September 2019 17:09 UTC
Return-Path: <justuswinter@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1CC12086E for <openpgp@ietfa.amsl.com>; Tue, 24 Sep 2019 10:09:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCtk-AUg_i-f for <openpgp@ietfa.amsl.com>; Tue, 24 Sep 2019 10:09:17 -0700 (PDT)
Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB0F12080D for <openpgp@ietf.org>; Tue, 24 Sep 2019 10:09:16 -0700 (PDT)
Received: by mail-ed1-x541.google.com with SMTP id t3so2492259edw.13 for <openpgp@ietf.org>; Tue, 24 Sep 2019 10:09:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=x1/fsJ/Hx/hyiZA3q/gBgq5TbIw7hqr3MdO/wCsb4yQ=; b=AGh08ECUfJ3foZCSnvTFn2r6v8Hxx4WstoNnZicvU60KsHmKRFJKsQH9oekOv6LeKy FVk95SGlHDMhJcDGZ7LFwEFfdHOSaEJTIBrv9zlaoMpkDulBuVkHzbv+oeJb8nNiTBVk agYj59eeJ10gqK/jglHjWuQ8lBkRnyZXGtMWXiZwxUdEm4OALng42M70mZLP4INQBPvv b+Lhc/glCMikf9HtfuKvbo7z8OQHACh6LuGqKmd4iGjCBKlnvOHyeWRWa469mE5bw9C2 cPzsBuVZEpNEWqTCWD5invwodj12TDWicZHFvkeqltq9wh5SurqXVorx6lB5A3n5W6OO b+Pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=x1/fsJ/Hx/hyiZA3q/gBgq5TbIw7hqr3MdO/wCsb4yQ=; b=TKWo2u6G/wShyHlLn9RTSydSn78XsM1xefTsrQCO9JrXNBZYAlGqkbgRx3Gcv9P1Jp ESrYk2NUdY6FoeExS0SXqGsIAjXCS169GaqzTPE+tT0kesSFUy0Z+YjqBPQZw3qZFmLP 1NVKT1R4HdqUQ1QZuiaUG8DSVQp8nALVch/qO6W8LnDaH7BoAbj9c8j6hAnzRA5xGv9N Al1cCHJOQ6HJizkNzcrxhjCUwE/PbBr5H5K4bafyJSsz4CDGyMlgdnyG1SuzjlwiA7uQ Ok4l/BUV0TCgG7JOe5Ya8JzqcItqIBJpJ0YaL/kI/YM/UFL/YT+2iKASKcx7Oyjxl026 yBtA==
X-Gm-Message-State: APjAAAWsClLIKPi/ioQLOS0t4vkOgaacSZkqEWJzswh9J++Q0sjzPmTQ 3S7QX3oi3IPqNXFyPCBw3Lb8C8pr158r3zTO5aqALOQd
X-Google-Smtp-Source: APXvYqwX50jsbWT8CBdJKveBamsqG4WctltVwgnYSLWzqbCdZmnPGieWIVpDCpqWaiHcfATgjWwdXPLqYbAQTXXfz+M=
X-Received: by 2002:a17:906:4ad2:: with SMTP id u18mr3467690ejt.117.1569344955335; Tue, 24 Sep 2019 10:09:15 -0700 (PDT)
MIME-Version: 1.0
From: Justus Winter <justuswinter@gmail.com>
Date: Tue, 24 Sep 2019 19:09:04 +0200
Message-ID: <CA+t5QVsZoWEuDWEzGn+mWNsx+giJsq+9pYptt3TfffASBVoGsw@mail.gmail.com>
To: openpgp@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/wnwdiGRBrKpJos_djj6bgPd0IWU>
Subject: [openpgp] Message padding in OpenPGP
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2019 17:09:20 -0000
Hello :) To reduce the amount of information leaked via the message length (see e.g. [0]), encrypted OpenPGP messages should include decoy traffic. 0: https://mailarchive.ietf.org/arch/msg/openpgp/rG-X9rp2jlbyACoosnbxRXjCeys There are a number of ways to add decoy traffic within the boundaries of the OpenPGP protocol, keeping an eye on backwards-compatibility with common implementations: - Add a decoy notation to a signature packet (up to about 60k) - Add a signature with a private algorithm and store the decoy traffic in the MPIs (up to 4 GB) - Use a compression container and store the decoy traffic in a chunk that decompresses to the empty string (unlimited) - Use a bunch of marker packets, which are ignored (each packet: 3 bytes for the body, 5 bytes for the header) - Apparently, GnuPG understands a comment packet (tag: 61), which is not standardized (up to 64k) Out of these options, the compression container is a simple and flexible candidate, that also has very good expected compatibility. We are currently convinced that padding the compressed data stream is the best option, because as far as OpenPGP is concerned, it is completely transparent for the recipient (for example, no weird packets are inserted). Testing some OpenPGP implementations (Sequoia, OpenKeychain, GnuPG) revealed no problems. To be effective, the padding layer must be placed inside the encryption container. To increase compatibility, the padding layer must not be signed. That is to say, the message structure should be (encryption (padding ops literal signature)), the exact structure GnuPG emits by default. An example of such a message is: -----BEGIN PGP MESSAGE----- wV4Di9iOlMDSAzMSAQdALBAMZRuLecJf8LZvPIYhTrqmN6BLN5fEc8m7sPZAPSYw 6lm9Nmm9fo5ogkLknC4E+ME8S9v5lCJVAMZ30OXNX5is/uvdzPh3csS4I2F07Q2C 0lMBznfsZ0N0N+fz3U2jR5kyM68Vj2/W7XrIaiG7DgPe8wGJkzYMVOiXDqzLa/fh sQH/IFpfjJQl0lCCZ2NKnIEG4s8S5eCINZZyipcGnKtrsvVviA== =kp0k -----END PGP MESSAGE----- The session key is 58FBB6C39FA3626AA283E47A01690957D0B866392B9CC79E53E943FF410ED6DB. You can view the message on [1], note the two padding bytes "wy" at the end of the compressed data stream. 1: https://dump.sequoia-pgp.org/?data=-----BEGIN%20PGP%20MESSAGE-----%0D%0A%0D%0AwV4Di9iOlMDSAzMSAQdALBAMZRuLecJf8LZvPIYhTrqmN6BLN5fEc8m7sPZAPSYw%0D%0A6lm9Nmm9fo5ogkLknC4E%2BME8S9v5lCJVAMZ30OXNX5is/uvdzPh3csS4I2F07Q2C%0D%0A0lMBznfsZ0N0N%2Bfz3U2jR5kyM68Vj2/W7XrIaiG7DgPe8wGJkzYMVOiXDqzLa/fh%0D%0AsQH/IFpfjJQl0lCCZ2NKnIEG4s8S5eCINZZyipcGnKtrsvVviA%3D%3D%0D%0A%3Dkp0k%0D%0A-----END%20PGP%20MESSAGE-----%0D%0A&hex=on&session_key=58FBB6C39FA3626AA283E47A01690957D0B866392B9CC79E53E943FF410ED6DB The following patch adds a section to RFC4880bis detailing the process of padding, and recommends a suitable padding policy. diff --git a/middle.mkd b/middle.mkd index ca73704..beb6f57 100644 --- a/middle.mkd +++ b/middle.mkd @@ -2397,6 +2397,26 @@ ZLIB-style blocks. BZip2-compressed packets are compressed using the BZip2 [](#BZ2) algorithm. +### Message padding + +The Compressed Data packet presents an opportunity to add an arbitrary +amount of decoy traffic to OpenPGP Messages. To that end, +implementations SHOULD create a encrypted, compressed message as +usual, and SHOULD use the ZIP algorithm with no compression +(i.e. level 0), and append a number of random bytes to the compressed +data stream according to a padding policy. Note: Not actually +compressing the data stream is important to make sure the size of the +padded message does not depend on the entropy of the plaintext +message. + +Implementations SHOULD use the Padmé padding scheme. Padmé offers the +same protection as the obvious scheme of padding to the next power of +two, but with an overhead of at most most 12%, decreasing with message +size. + +See Section 4 of [Reducing Metadata Leakage from Encrypted Files and +Communication with PURBs](https://bford.info/pub/sec/purb.pdf). + ## Symmetrically Encrypted Data Packet (Tag 9) The Symmetrically Encrypted Data packet contains data encrypted with a Cheers, Justus
- [openpgp] Message padding in OpenPGP Justus Winter
- Re: [openpgp] Message padding in OpenPGP Ryan Carboni
- Re: [openpgp] Message padding in OpenPGP Heiko Stamer
- Re: [openpgp] Message padding in OpenPGP Jon Callas
- Re: [openpgp] Message padding in OpenPGP Justus Winter
- Re: [openpgp] Message padding in OpenPGP Derek Atkins
- Re: [openpgp] Message padding in OpenPGP Jon Callas
- Re: [openpgp] Message padding in OpenPGP vedaal
- Re: [openpgp] Message padding in OpenPGP Justus Winter
- Re: [openpgp] Message padding in OpenPGP Daniel Kahn Gillmor
- Re: [openpgp] Message padding in OpenPGP Stephen Farrell
- Re: [openpgp] Message padding in OpenPGP Daniel Kahn Gillmor
- Re: [openpgp] Message padding in OpenPGP Stephen Farrell
- Re: [openpgp] Message padding in OpenPGP Derek Atkins
- Re: [openpgp] Message padding in OpenPGP Justus Winter
- Re: [openpgp] Message padding in OpenPGP Daniel Kahn Gillmor