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

Daniel Huigens <d.huigens@protonmail.com> Tue, 02 August 2022 18:01 UTC

Return-Path: <d.huigens@protonmail.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 097E3C157B5F for <openpgp@ietfa.amsl.com>; Tue, 2 Aug 2022 11:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com
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 8g73B7XokRD1 for <openpgp@ietfa.amsl.com>; Tue, 2 Aug 2022 11:01:46 -0700 (PDT)
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA59C14F747 for <openpgp@ietf.org>; Tue, 2 Aug 2022 11:01:46 -0700 (PDT)
Date: Tue, 02 Aug 2022 18:01:41 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1659463303; x=1659722503; bh=7CxrweLFV5R9DOgmoEWOsSbDSpfrcNjyDBDuzdCaqxk=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=kwkmJfVmjADpVikA697556iIB0R2Ic3VbnqG0XsO/w4EWL8PV4AulJjkbiADm4A6Q /oB/d4xY3dhUO4hD0+zsRtkcY6hjflAxiekiIyGTDHIv91Db4GBU1JiwMq2mu8mFbM zF4fWdqFGgjRwErxvxmG6OL9ZHc9prFzTenedjKOg9noBiIAAlwTzyAWX3Z0aGpEJM P1ohY8fROFSdczA6h0ycjtzKp41jqcvomR1S5OQxgl6XnoCa8xiCz1TBdNUhiAqWNe /U+RNn/p6ikJHLJkAVq9Qb0x1kkAZL4BxEqnz0KidgYdJpzuM/xzUUJUvNabc0q70f 3KwvNtc81aIlg==
To: bwalzer@59.ca
From: Daniel Huigens <d.huigens@protonmail.com>
Cc: wk@gnupg.org, justus@sequoia-pgp.org, openpgp@ietf.org
Reply-To: Daniel Huigens <d.huigens@protonmail.com>
Message-ID: <Q6EUpbQm0e5f1OiU-77Old9p9FXyLCaFZ8pMm7PTt8VTLQJaXRQzWIDSwc3db6yI-56imyOaTNdt9TC8Zrm1jN_kPKxFYH4OqEu6o-Wfquo=@protonmail.com>
In-Reply-To: <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> <YulX9jI1+wOCwLJq@ohm.59.ca>
Feedback-ID: 2934448:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_UoqXcw3HaFMq0coZm8BDhR2oBdrSYaZmJ6rafQSc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/KGf_OZKNj9OgBaZdHmGG0Cy2YqU>
Subject: Re: [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 18:01:50 -0000

GCM is in the same category of constructs as OCB. It is not a semantic
mismatch to swap one for the other. The name "AEAD" is also not
(necessarily) exposed to users, it's mainly used internally in the
spec (/ implementation) to describe the category of algorithms used.

Additionally, our reason for wanting to use GCM is also for performance.
For us, GCM is (considerably) faster than OCB, as GCM is implemented
natively in Web Crypto. This makes the implementation both more secure
and faster than what we could ship in JS.

Best,
Daniel

------- Original Message -------
On Tuesday, August 2nd, 2022 at 12:59, Bruce Walzer wrote:

> 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
>
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp