Re: [openpgp] The combinatorial complexity of OpenPGPv4

Christoph Anton Mitterer <calestyo@scientia.net> Mon, 23 March 2015 18:48 UTC

Return-Path: <calestyo@scientia.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25A31AD2EE for <openpgp@ietfa.amsl.com>; Mon, 23 Mar 2015 11:48:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 sZhSmq3Q-hBU for <openpgp@ietfa.amsl.com>; Mon, 23 Mar 2015 11:48:33 -0700 (PDT)
Received: from mailgw01.dd24.net (mailgw-01.dd24.net [193.46.215.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BAB51AD2C0 for <openpgp@ietf.org>; Mon, 23 Mar 2015 11:48:33 -0700 (PDT)
Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.27]) by mailgw01.dd24.net (Postfix) with ESMTP id 39AC55FBA8 for <openpgp@ietf.org>; Mon, 23 Mar 2015 18:48:32 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mailpolicy-02.live.igb.homer.key-systems.net
Received: from mailgw01.dd24.net ([192.168.1.35]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-02.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10235) with ESMTP id j1jcfZu-z7-j for <openpgp@ietf.org>; Mon, 23 Mar 2015 18:48:30 +0000 (UTC)
Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw01.dd24.net (Postfix) with ESMTPSA for <openpgp@ietf.org>; Mon, 23 Mar 2015 18:48:30 +0000 (UTC)
Message-ID: <1427136508.10191.33.camel@scientia.net>
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: openpgp@ietf.org
Date: Mon, 23 Mar 2015 19:48:28 +0100
In-Reply-To: <sjmbnjrk5jy.fsf@securerf.ihtfp.org>
References: <55038CBE.7070608@iridiumlinux.org> <1160541985.95679.1426305437936.JavaMail.yahoo@mail.yahoo.com> <sjm3855m4r8.fsf@securerf.ihtfp.org> <CAA7UWsVocUNzUvK_oxSG8G6nq7s_qGhwZdewBnfmzQQpXcuAMw@mail.gmail.com> <sjmbnjrk5jy.fsf@securerf.ihtfp.org>
Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-EnM19BfePEtTggtsmKZ9"
X-Mailer: Evolution 3.12.9-1+b1
Mime-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/n-zhnitM9-hloMW4_CKXdt3xzjc>
Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 23 Mar 2015 18:48:35 -0000

On Tue, 2015-03-17 at 11:27 -0400, Derek Atkins wrote: 
> I don't agree with this statement.  It wasn't flexibility that stopped
> changing CFB, it was that CTR mode was relatively new when the group was
> working on 4880 (I'm not sure it even existed when we did 2440).  And
> compatibility was always (generally) paramount.  I.e., if it ain't
> completely broke let's not fix it..  and where it is broke, let's fix it
> in the most compatible way.
> 
> Were I do start from scratch today then yes, I'd just use GCM.  We could
> certainly add a GCM mode and a preference to specify support for it.
> But for interop I don't think we could drop CFB support completely from
> implementations.
Could you elaborate on that?

I probably lack some decent+recent cryptanalysis of CFB as used with
OpenPGP, but at least we had quite a number of crypto systems where it
caused all kinds of issues recently.

So *if* there's a new OpenPGP v.X (and not just "amendments" as with
Ed25519), shouldn't it be actually a goal to get current state of the
art things?


Cheers,
Chris.