Re: [openpgp] Message padding in OpenPGP

vedaal@nym.hush.com Wed, 25 September 2019 15:35 UTC

Return-Path: <vedaal@nym.hush.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 90D2B120025 for <openpgp@ietfa.amsl.com>; Wed, 25 Sep 2019 08:35:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.ai
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 3fcHV5FFMhG9 for <openpgp@ietfa.amsl.com>; Wed, 25 Sep 2019 08:35:43 -0700 (PDT)
Received: from smtp2.hushmail.com (smtp2.hushmail.com [65.39.178.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A5F120013 for <openpgp@ietf.org>; Wed, 25 Sep 2019 08:35:43 -0700 (PDT)
Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id 819F3A0B8C for <openpgp@ietf.org>; Wed, 25 Sep 2019 15:35:42 +0000 (UTC)
X-hush-tls-connected: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=YS9HPyio2sxTFlGaC30VXOGpA6K9XAxddIoY/Sbh+fE=; b=SNBc7BcVdYwGXYHSlbF5P7BA16J7basAPkTDjnAj5v71RJpyhDQsq2LIK5sBwYlT2rqf2UTuBo8S7cZalzGMS30Q9h0PklgCZKqpthZPCHnFGcS5bXoTBihC74MNRDlLoAP1PLZAlV28epjmeRF/UG47GfSkoKbNxnt68w8THr7oxv9DNM6ci8zNxgQg2Ipau127zucU2vBdQYZf+029rpIuIcUs2axgSgwn7eRKDfd5JCU8H2Ywh2p6bIsrLmKQEv+I3Oe3ObW1dUUV+juoSvXWn7NCDS+mQ6yiVxSyQwp5PzhC60iGnYyAmMmL9JwV5xaLtsiLCYjnfvSEoJXZig==
Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS for <openpgp@ietf.org>; Wed, 25 Sep 2019 15:35:42 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id 14A78200F9; Wed, 25 Sep 2019 15:35:42 +0000 (UTC)
MIME-Version: 1.0
Date: Wed, 25 Sep 2019 11:35:41 -0400
To: openpgp@ietf.org
From: vedaal@nym.hush.com
In-Reply-To: <CA+t5QVs7aoyBotbApmGQBGO9otLeB9knccAV8w9MacjrcE_51w@mail.gmail.com>
References: <CA+t5QVsZoWEuDWEzGn+mWNsx+giJsq+9pYptt3TfffASBVoGsw@mail.gmail.com> <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> <CA+t5QVs7aoyBotbApmGQBGO9otLeB9knccAV8w9MacjrcE_51w@mail.gmail.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20190925153542.14A78200F9@smtp.hushmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/hy8D0xBREAB_ZwShkwsAxI76saU>
Subject: Re: [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: Wed, 25 Sep 2019 15:35:46 -0000

On 9/25/2019 at 5:04 AM, "Justus Winter" <justuswinter@gmail.com> wrote:

>There is a correlation between the size of the encrypted message 
>and the size of the plaintext.  On first sight, compression helps with
>that, but that makes the size dependent on the entropy of the
>plaintext, which also leads to problems as discussed previously.
>Padding alleviates this problem, the tradeoff being an increased
>message size.

=====

It really doesn't matter once the message is past a certain length.
Whatever correlation there might be with the plaintext and message size,
once the message is long enough, attackers can't do more than speculate about the plaintext content.

For very short messages, 
it's enough if the sender just presses the spacebar at the end of the message until the plaintext is the desired size.
(And even then, only if the sender feels that there might be some vulnerability with the size of the plaintext, which is usually not the case. )

In any event, it's enough if there is a cautionary note in the rfc about the correlation between plaintext size and encryption, and suggest, that if this is an issue for the sender and receiver, then a workaround could be to simply add some padding at the end which doesn't interfere or obscure the content of the plaintext.


vedaal