Re: [openpgp] The combinatorial complexity of OpenPGPv4
Derek Atkins <warlord@MIT.EDU> Tue, 17 March 2015 15:27 UTC
Return-Path: <derek@ihtfp.com>
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 4FDD01A1BF3 for <openpgp@ietfa.amsl.com>; Tue, 17 Mar 2015 08:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 d5Ux_aFPw1as for <openpgp@ietfa.amsl.com>; Tue, 17 Mar 2015 08:27:36 -0700 (PDT)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE081A1B8B for <openpgp@ietf.org>; Tue, 17 Mar 2015 08:27:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3E1EBE2039; Tue, 17 Mar 2015 11:27:35 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 04074-01; Tue, 17 Mar 2015 11:27:32 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 5F31FE2038; Tue, 17 Mar 2015 11:27:32 -0400 (EDT)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2HFRTgm027284; Tue, 17 Mar 2015 11:27:29 -0400
From: Derek Atkins <warlord@MIT.EDU>
To: David Leon Gil <coruus@gmail.com>
References: <55038CBE.7070608@iridiumlinux.org> <1160541985.95679.1426305437936.JavaMail.yahoo@mail.yahoo.com> <sjm3855m4r8.fsf@securerf.ihtfp.org> <CAA7UWsVocUNzUvK_oxSG8G6nq7s_qGhwZdewBnfmzQQpXcuAMw@mail.gmail.com>
Date: Tue, 17 Mar 2015 11:27:29 -0400
In-Reply-To: <CAA7UWsVocUNzUvK_oxSG8G6nq7s_qGhwZdewBnfmzQQpXcuAMw@mail.gmail.com> (David Leon Gil's message of "Mon, 16 Mar 2015 14:58:08 -0700")
Message-ID: <sjmbnjrk5jy.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/QgK-0c0TwAcEWP656FQ57N3Rckk>
Cc: David Gil <dgil@yahoo-inc.com>, "openpgp@ietf.org" <openpgp@ietf.org>, Falcon Darkstar Momot <falcon@iridiumlinux.org>
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: Tue, 17 Mar 2015 15:27:38 -0000
David Leon Gil <coruus@gmail.com> writes: > On Monday, March 16, 2015, Derek Atkins <warlord@mit.edu> wrote: [snip] > Having implemented it myself, I disagree completely. It is absolutely > possible to create a modular implementation. See my Usenix Security > Talk on the PGP Message Processing Pipeline from.... 1996?? > > Well, first: You're Derek Atkins. Not everyone is as good of a coder. *blush* > Second: It is hard to *prove* modularity, because of how complicated the > semantics are. (I have been trying, off-and-on, using Frama-C, for a while.) Yes, the structure is complicated (my parser state machine had something like 150-200 states). But the processing itself is completely modular. You just need concepts like split and join along the pipeline to handle it. Proof by existance? > [snip] > >> Protocol modularity is not evil. > > > > Modularity is neutral. "Agility", as folks like to call it, is evil. > > Well, it's a damn good thing we've had agility otherwise we'd have been > stuck with 3DES, SHA1 (or MD5!!), and probably either RSA or maybe > DSA/Elgamal. > > No: The reason there hasn't been any urgency to fix things like the CFB mode > problems, or the MDC, is that the current standard is too flexible. 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. I'll also point out that CFB vs "something else" (i.e., "mode agility") is completely orthogonal to algorithm agility. OpenPGP does NOT have decent mode agility; we would need to add a new packet type for that. > I hate to use TLS as an exemplar of anything, but they have done a much better > job in this regard recently. > > Where it is easy to provide flexibility, it is rarely useful. Where it is > useful, it is rarely feasible to provide. (E.g., a parameter to choose SIV, > encrypt-then-MAC, or robust AE.) It's easy to add it if you think about it ahead of time (and put in the parameterization). It's harder to add it after-the-fact. This is true in both TLS and OpenPGP. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available
- Re: [openpgp] The combinatorial complexity of Ope… David Gil
- Re: [openpgp] The combinatorial complexity of Ope… Derek Atkins
- Re: [openpgp] The combinatorial complexity of Ope… Derek Atkins
- Re: [openpgp] The combinatorial complexity of Ope… David Leon Gil
- Re: [openpgp] The combinatorial complexity of Ope… Peter Gutmann
- Re: [openpgp] The combinatorial complexity of Ope… Werner Koch
- Re: [openpgp] The combinatorial complexity of Ope… Derek Atkins
- Re: [openpgp] The combinatorial complexity of Ope… Christoph Anton Mitterer
- Re: [openpgp] The combinatorial complexity of Ope… Phillip Hallam-Baker
- [openpgp] The combinatorial complexity of OpenPGP… David Leon Gil
- Re: [openpgp] The combinatorial complexity of Ope… Falcon Darkstar Momot