Re: [openpgp] OpenPGP encryption block modes

Bruce Walzer <bwalzer@59.ca> Fri, 12 August 2022 16:21 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 F3D3BC14F729 for <openpgp@ietfa.amsl.com>; Fri, 12 Aug 2022 09:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 x2ybJ8ye4D2r for <openpgp@ietfa.amsl.com>; Fri, 12 Aug 2022 09:21:15 -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 E5F42C15C504 for <openpgp@ietf.org>; Fri, 12 Aug 2022 09:20:12 -0700 (PDT)
Received: from [104.246.140.18] (helo=watt.59.ca) by mail.59.ca with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <bwalzer@59.ca>) id 1oMXOL-000KMl-El; Fri, 12 Aug 2022 11:20:09 -0500
Date: Fri, 12 Aug 2022 11:20:07 -0500
From: Bruce Walzer <bwalzer@59.ca>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: openpgp@ietf.org
Message-ID: <YvZ9txWreYSbzyBi@watt.59.ca>
References: <87bktajjvq.fsf@thinkbox> <YuKpxp0/Dy1DfC19@watt.59.ca> <875yjhjg2c.fsf@thinkbox> <87r124m64c.fsf@wheatstone.g10code.de> <YulX9jI1+wOCwLJq@ohm.59.ca> <Q6EUpbQm0e5f1OiU-77Old9p9FXyLCaFZ8pMm7PTt8VTLQJaXRQzWIDSwc3db6yI-56imyOaTNdt9TC8Zrm1jN_kPKxFYH4OqEu6o-Wfquo=@protonmail.com> <YuvlHdLz0Sfle7Ot@ohm.59.ca> <87a68ji1bv.fsf@wheatstone.g10code.de> <YvPGY8ArcKD7Hr1p@watt.59.ca> <YvQoC1g5rzKCfCVp@tapette.crustytoothpaste.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <YvQoC1g5rzKCfCVp@tapette.crustytoothpaste.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/-LDqKdqgOhqGBtM12bxwAthsQZM>
Subject: Re: [openpgp] OpenPGP encryption block modes
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: Fri, 12 Aug 2022 16:21:18 -0000

On Wed, Aug 10, 2022 at 09:50:03PM +0000, brian m. carlson wrote:
[...]
> > That raises a question for me as I hold the position that OpenPGP does
> > not need any more block cipher modes. I had the impression that
> > SEIP-MDC (OCFB-MDC) would be relatively fast as the slow part is
> > SHA1. SHA1 is one of the faster cryptographic hashes and is hardware
> > accelerated on common platforms. I assumed that the slowness was
> > because no one had ever bothered to optimize things. Is this true?
> 
> SHA-1 is no longer considered secure, and thus we can't assume that a
> SHA-1 hash of the data intrinsically indicates that it hasn't been
> changed.

I don't think this is correct as stated for normal OpenPGP usage. SHA1
is only broken for collisions. The best an attacker can do is
create two messages that when hashed with SHA1 will come out to the
same value. So SHA1 does in fact prevent an entity other than the
originator from making an undetected change. Fortunately this
distinction is entirely irrelevant for SHA1 use in OCFB-MDC. The hash
used only requires the property of irreversibility.

> Some OpenPGP implementations are trying to avoid known attacks by using
> the same collision-detecting SHA-1 implementation that Git uses, which
> is extraordinarily slow and can't be accelerated due to the need for
> intermediate products.  (This is why moving to Git's new SHA-256
> repositories will tend to improve performance somewhat on modern
> machines, as well as improving security.)

I would be interested in a reference. It would be helpful here to know
how well the workaround actually works in practice. Such a workaround
is not required for OCFB-MDC as it is completely secure using regular
SHA1.

And that is the point we really should address here. We have a working
and well standardized block cipher mode. It seems to make no sense to
add three new block cipher modes for a total of five in the standard
(OCFB still exists and is in current use). We have even had to create
a preferences system just for the block cipher mode. Would any of
this make any rational sense in any other context? Why does it make
sense in this context?

Bruce