IETF Logo Mail Archive

Re: [openpgp] Message padding in OpenPGP

Jon Callas <joncallas@icloud.com> Tue, 24 September 2019 21:00 UTC

Return-Path: <joncallas@icloud.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 57C131200DB for <openpgp@ietfa.amsl.com>; Tue, 24 Sep 2019 14:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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=icloud.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 w61FxY4RJkje for <openpgp@ietfa.amsl.com>; Tue, 24 Sep 2019 14:00:21 -0700 (PDT)
Received: from mr85p00im-zteg06022001.me.com (mr85p00im-zteg06022001.me.com [17.58.23.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812FB120020 for <openpgp@ietf.org>; Tue, 24 Sep 2019 14:00:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1569358820; bh=8Jcbo8v29a5E2vfaDzxiv2Wy+cXberHGxnA+zmDVH8A=; h=Content-Type:Subject:From:Date:Message-Id:To; b=nskes9A2uX9AN8ATW+P/K+9NgcF18j7AYTBynHntOnTHiLHnFn/ihKlCfjZell82Y QYyyRIQRZ8ylP5qePIssViiGWGqs+unTgfTiGSizN1ivr9BTBImG7tLmXDzoUm32iv C+Vwmo4biDY3bNn3tK5xlrc4HpAsccKRFpUz0cwst4BQ4AiMy/OurSC7oPkhDhOOc9 oqTIiesIt8uEDYAGHMcVgU6q7jv8FyNxB1eTHuS8Z6t66P1UBmqj9sckUSPczv7XD2 kpmPhq2h46+2okJOo35WTdb60qL7JRFiEC7g3qVj9os/C7wS9USTt77+C1rPUHmKG1 7KvHM4Oh/J7bw==
Received: from [10.70.126.231] (unknown [38.109.115.130]) by mr85p00im-zteg06022001.me.com (Postfix) with ESMTPSA id 8ADDE9003DC; Tue, 24 Sep 2019 21:00:19 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Jon Callas <joncallas@icloud.com>
In-Reply-To: <CA+t5QVsZoWEuDWEzGn+mWNsx+giJsq+9pYptt3TfffASBVoGsw@mail.gmail.com>
Date: Tue, 24 Sep 2019 17:00:17 -0400
Cc: Jon Callas <joncallas@icloud.com>, openpgp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com>
References: <CA+t5QVsZoWEuDWEzGn+mWNsx+giJsq+9pYptt3TfffASBVoGsw@mail.gmail.com>
To: Justus Winter <justuswinter@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-24_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=961 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909240169
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/14OCpAm0ZqdmK_Sghiy2vgZQwM4>
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: Tue, 24 Sep 2019 21:00:23 -0000


> On Sep 24, 2019, at 1:09 PM, Justus Winter <justuswinter@gmail.com> wrote:
> 
> 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

What actual problem are you trying to solve.

We've discussed compressed data at length, and there's a general consensus to my mind that implementations should move away from compression being the default. There's less of a consensus that it should go the way of all things, into that good night. But we agree that compression is at the very least a can of worms.

Am I correct in understanding that you're proposing adding in decoy traffic to pad out compressed data to its uncompressed length? 

If I'm missing something, what problem are you trying to solve with this?

	Jon

v2.23.0 | Report a Bug | By Email