[openpgp] OpenPGP encryption block modes (Was: The Argon2 proposal seems incomplete (Draft 6))

Bruce Walzer <bwalzer@59.ca> Tue, 02 August 2022 16:59 UTC

Return-Path: <bwalzer@59.ca>
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 EDBABC14CF1D for <openpgp@ietfa.amsl.com>; Tue, 2 Aug 2022 09:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0CPbos2AG2b for <openpgp@ietfa.amsl.com>; Tue, 2 Aug 2022 09:59:41 -0700 (PDT)
Received: from mail.59.ca (mail.59.ca [205.200.229.83]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD2FC14F74E for <openpgp@ietf.org>; Tue, 2 Aug 2022 09:59:41 -0700 (PDT)
Received: from [10.0.0.2] (helo=ohm.59.ca) by mail.59.ca with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.94.2) (envelope-from <bwalzer@59.ca>) id 1oIvF1-000KFx-Qb; Tue, 02 Aug 2022 11:59:36 -0500
Date: Tue, 02 Aug 2022 11:59:34 -0500
From: Bruce Walzer <bwalzer@59.ca>
To: Werner Koch <wk@gnupg.org>
Cc: Justus Winter <justus@sequoia-pgp.org>, openpgp@ietf.org
Message-ID: <YulX9jI1+wOCwLJq@ohm.59.ca>
References: <YuAErZRsF/KbOw1s@watt.59.ca> <87edy7keb6.fsf@thinkbox> <YuFc+w02FiRQmHcg@watt.59.ca> <87bktajjvq.fsf@thinkbox> <YuKpxp0/Dy1DfC19@watt.59.ca> <875yjhjg2c.fsf@thinkbox> <87r124m64c.fsf@wheatstone.g10code.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87r124m64c.fsf@wheatstone.g10code.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/zHZAJAlM5KeGAMik49Hr-IR18ok>
Subject: [openpgp] OpenPGP encryption block modes (Was: The Argon2 proposal seems incomplete (Draft 6))
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
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, 02 Aug 2022 16:59:44 -0000

On Fri, Jul 29, 2022 at 02:54:27PM +0200, Werner Koch wrote:
> On Thu, 28 Jul 2022 19:35, Justus Winter said:
> > The current SEIPv1+MDC is impossible to implement securely.  Efail, one
> > of the best attacks on OpenPGP ever, is a direct consequence of that.
> 
> EFail has never been an attack on OpenPGP.  It is an attack on the
> majority of todays mail clients implementations.  We have seen other
> attacks which were more severe.
> 
> > whether a replacement for the SEIPv1+MDC system is needed.
> 
> CFB+MDC is a proper encryption system the we came up in 2000 with still
> no known attacks.  It is slow, though.  Thus a faster and easy to
> implement AE mode makes a lot of sense.  This is why we started to
> deploy OCB decryption capability years ago, so that in a few years it
> can replace the CFB+MDC mode.

Greater performance *is* a legitimate rationale for another block mode. I have been arguing that OpenPGP based systems have been implicitly depending on the inherent modification deterrence of SEIP to the extent that the MDC is mostly ignored. Because of that I have to admit that OCB has much better inherent modification detection. Modifications on OCB damage the block modified, not the next one as with SEIP. So if we had to have another block mode (I am still not convinced of this) then OCB would seem a particularly rational choice.

> 
> The whole new complex "crypto-refresh" AE stuff to support the brittle
> GCM is a dead end.  Well, unless you want to put OpenPGP back into the
> geek-only domain.

I think the problem of extraneous block modes like GCM came from the
decision to start calling the block mode "AEAD". Once there was an
apparent slot opened up with that name only then did people start
thinking of things to drop into that slot. So GCM could be seen as an
example of an inappropriate graft from another regulatory medium based
on confusion of terminology.

AEAD isn't even a very accurate term in an OpenPGP context. There is
no AD (associated data) exposed to the user of such a system. It just
doesn't work that way.

Bruce