Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis

Werner Koch <wk@gnupg.org> Fri, 27 October 2017 10:54 UTC

Return-Path: <wk@gnupg.org>
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 B50CB13F4F0 for <openpgp@ietfa.amsl.com>; Fri, 27 Oct 2017 03:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
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 4eJ7xZpqg6pk for <openpgp@ietfa.amsl.com>; Fri, 27 Oct 2017 03:54:05 -0700 (PDT)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 542D613F46A for <openpgp@ietf.org>; Fri, 27 Oct 2017 03:54:05 -0700 (PDT)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1e82H5-0004L4-9M for <openpgp@ietf.org>; Fri, 27 Oct 2017 12:54:03 +0200
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1e82DA-0004Rg-8e; Fri, 27 Oct 2017 12:50:00 +0200
From: Werner Koch <wk@gnupg.org>
To: Ronald Tse <tse@ribose.com>
Cc: "openpgp\@ietf.org" <openpgp@ietf.org>
References: <D0505748-E376-4CF9-8906-9AD77838FB23@ribose.com> <1508981649515.71466@cs.auckland.ac.nz> <07C9EFDF-C8C2-4433-A9F9-DC3D7AFD5499@ribose.com> <6AC83857-62D9-45DF-9DAE-928CF0E45A96@nohats.ca> <87she556tv.fsf@wheatstone.g10code.de> <1509093954061.51049@cs.auckland.ac.nz> <36023233-856C-4A6D-BAF9-28037B4DA0F7@ribose.com>
Organisation: The GnuPG Project
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: Ronald Tse <tse@ribose.com>, "openpgp\@ietf.org" <openpgp@ietf.org>
Date: Fri, 27 Oct 2017 12:49:59 +0200
In-Reply-To: <36023233-856C-4A6D-BAF9-28037B4DA0F7@ribose.com> (Ronald Tse's message of "Fri, 27 Oct 2017 10:12:51 +0000")
Message-ID: <8760b06f1k.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=Attorney_General_asset_Indigo_Peking_Ft._Bragg_USCOI_Baranyi_InfoSec"; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/lOLo_0g036o1Bift92qkw7SBe4s>
Subject: Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.22
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, 27 Oct 2017 10:54:07 -0000

Hi!

[I am only wearing my GnuPG maintainer's hat right now.]

On Fri, 27 Oct 2017 12:12, tse@ribose.com said:

> Again, OCB is proposed to be a MAY algorithm, not a MUST or even a SHOULD — if someone doesn't like it, there is no need to prevent others from using it.

Well, I would like to implement OCB in GnuPG at least to be prepared for
the time after the patent(s) expiration.  It will not be the default any
time soon.

I already remarked that I expect that it will take a couple of years
before gpg with _any_ AEAD mode will be widely enough deployed so that
an AEAD mode can actually be used.  We have seen that it took many years
before we could enforce the MDC mode despite that there is a key flag
announcing it.  It is unfortunate that we need to implement EAX for the
very same reason that PGP5 had to use DSA/Elgamal instead of RSA.  But
delaying an AEAD mode even further would be worse.

The patent situation is actually different between RSA+IDEA and OCB.
For the former the holders of the patent went aggressively against
everyone using them.  For the latter the patent holder(s) gave explicit
royalty free grants for almost all use cases.  And the patents will
expire in a few years - modulo the usual uncertainty with the patent
system.

Peter suggested to use encrypt-then-MAC to avoid all problems.  This
would require an entire different structure of the symmetric encryption
code and thus adds complexity for a theoretical benefit over the MDC
approach.  We would still need to double process the data.

Having an option to allowing switch the AEAD mode will be easier than to
implement both, encrypt-then-MAC and one AEAD mode.



Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.