Re: [openpgp] Modernizing the OpenPGP Format draft

Bryan Ford <> Mon, 02 November 2015 23:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CC9D51A9069 for <>; Mon, 2 Nov 2015 15:30:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IovE3Vh6WM-T for <>; Mon, 2 Nov 2015 15:30:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 743981A906D for <>; Mon, 2 Nov 2015 15:30:31 -0800 (PST)
Received: by padec8 with SMTP id ec8so53115979pad.1 for <>; Mon, 02 Nov 2015 15:30:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=D9GLTTGRO1Db8dTGII+IRSCK2mj5HjHcC1nGMsYWGPk=; b=KyeTi3EVyLsBndUXRPrXtkSSR1VYUSStQAHYtlnKJP1KUFvnj3vNrtL3n7+WP/JmJu GnNYJkmM64FMEDBd49mjsc4epqVAWFRFxp4UJmnsIfCRKyNbn5Yl1HCJRGZ15wV+zjK7 hi/X/n1T6GYEFtEr/WnrhQ4d4/cklfM7inHbuU5TWMm+24xOn7CU6PlQ/x85iV19nvuv Nrr6fiCdBDPeoswR24HHyghVkdfSUMxmujFyoD60Xwuhq7ijL/OBwigweI9BoH7Lo734 GGJl1XdaAetJ3nOzmWdKv52LoW84XTHGoNHZGa/fvq2IQ7cUL/m3QfwyiB0RH7s1Ycc/ 100g==
X-Received: by with SMTP id bh5mr30378886pbb.160.1446507031172; Mon, 02 Nov 2015 15:30:31 -0800 (PST)
Received: from ( [2001:c40:0:3032:c957:b0a9:225a:62d2]) by with ESMTPSA id tt7sm26093991pab.45.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Nov 2015 15:30:30 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_749C7FA0-B5FB-4A86-B363-E0E0FC4282F9"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Bryan Ford <>
In-Reply-To: <>
Date: Tue, 3 Nov 2015 08:30:26 +0900
Message-Id: <>
References: <> <>
To: ianG <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Subject: Re: [openpgp] Modernizing the OpenPGP Format draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Nov 2015 23:30:34 -0000

Thanks Ian for the great feedback.

Indeed, I think in all the places the draft says ‘identity protection’ it should say ‘integrity protection’, sorry about the confusion.  That was just me mixing up i-words as I was deliriously hammering out text half an hour before the I-D submission deadline. ;)

> On Nov 3, 2015, at 7:05 AM, ianG <> wrote:
> nonce as 0 for non-reuse - disagree.  I would strongly prefer the nonce to always be there and always be randomly generated by requirement, because we can't trust the rest of the software.  Multiple, redundant protections are great when they are free.  Which they are in this case.  Nonce to be always present, big and random, and the secret key should not be re-used.

That’s completely reasonable, and I’d be fine with that in the interest of caution and bug-resilience.

>> It covers two topics, the first being the AEAD evolution, the second
>> being a somewhat more ambitious idea to provide better metadata
>> protection and anonymization properties at the "outer-wrapper" level;
>> see the draft for (some more, still sketchy) details.
> 2.3 also good, I'm very keen on that. The "bucket expansion" scheme is likely to signal which tool was used, unless we can convince other packages to do that (pretty unlikely).

Great.  My hope is that if we were to specify the padding/bucket-expansion mechanism in a separate document in an application-neutral way and with the relevant theory spelled out, we might eventually be able to convince other applications to use or migrate to such a scheme too.  But that would be a long-term goal, and whether or not it happens it would have to start somewhere, and to me OpenPGP seems like a reasonable place for it to start. ;)

By the way, I have a draft-of-a-draft of a document with more details on the metadata protection and padding schemes I have in mind; it obviously didn’t make the I-D deadline and still has major holes but I’m happy to share it informally with anyone interested.