Re: [Cfrg] Postquantum cryptography in IETF protocols

"Paterson, Kenny" <> Wed, 22 March 2017 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60B18131741 for <>; Wed, 22 Mar 2017 07:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V5UcgRCxkcLT for <>; Wed, 22 Mar 2017 07:36:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3147E131746 for <>; Wed, 22 Mar 2017 07:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=au6ojWBNjQnjugRb5F+t5tqrjt5tKTM/t+2V5cNjbWY=; b=2iW1+cA2edyvOmaXSJC4H7lbIscgg80Kr/4Dn62Ol4rRbIy5imLH9XptaCiFeEIdP103sNaP7ZqJkGDEHfxLyVtVBjU0UDUZ5fEGbUvJ+gZk4w749VOGJuY6rw/V6uiHrnctXNQ08lDr/718QtqTl9tRb2s+gVqPmQ95tRkI2r4=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.11; Wed, 22 Mar 2017 14:36:05 +0000
Received: from ([]) by ([]) with mapi id 15.01.0977.019; Wed, 22 Mar 2017 14:36:04 +0000
From: "Paterson, Kenny" <>
To: William Whyte <>
CC: Watson Ladd <>, "Tams, Benjamin" <>, "" <>
Thread-Topic: [Cfrg] Postquantum cryptography in IETF protocols
Thread-Index: AQHSnTVJcjR350Po60+E6F5IvEbv/KGVkP8AgAtEM4CAAAGqgIAAIo8A
Date: Wed, 22 Mar 2017 14:36:04 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1906; 7:lHjqncQuoIvvvUVyrEFUYy0fJSdBistw5Q6egkX8MKkatGfX+GaxQu06Pd1YPmga+4t0QUoKyIqeDIGOVir9pv2dZiqrolxQO+xPkk5kPgowG9Xuwh7AsTO8i9qNm4FnquGpKvA3cfSXpXQTdkTDduaJoo/ee+UJsfzYqa5/mHdCNYiDavh0YGqleX3tgy4JgwAG31y1mhlv4MKykEHLm7qCPFNhP6GwozsvbIdfRNCw9pna2BUsmwqV19UDecuk6NfZvD5MWQTXB4Z7VnXysysa7RmD2dTsnZHMAWXmGL3ESqsTNVG0R0yVApUiU6F6lbUTPLbcsoVd3liVDiFznw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(52314003)(24454002)(377454003)(2906002)(3846002)(8936002)(305945005)(50986999)(54906002)(2950100002)(6916009)(39060400002)(42882006)(4001350100001)(99286003)(6436002)(38730400002)(6512007)(83506001)(74482002)(53936002)(6306002)(110136004)(53546009)(54356999)(6486002)(229853002)(102836003)(122556002)(6246003)(561944003)(6506006)(189998001)(3660700001)(36756003)(86362001)(66066001)(4326008)(2900100001)(7736002)(77096006)(76176999)(3280700002)(81166006)(8676002)(5660300001)(93886004)(25786009)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
x-ms-office365-filtering-correlation-id: 3e58d3c0-cb85-4257-e71d-08d47130c52b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM4PR0301MB1906;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(166708455590820)(266576461109395);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1906;
x-forefront-prvs: 02543CD7CD
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2017 14:36:04.5009 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906
Archived-At: <>
Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Mar 2017 14:36:43 -0000

Hi William,

You are right that there's no formally agreed approach for CFRG, but the
current approach that the *leadership* of CFRG (i.e. the co-chairs) would
like to take is that explained in my message below. But we can of course
revisit the question as a research group.

To reiterate: I would consider it a mistake for CFRG to go down the route
of standardising PQ algorithms ahead of the NIST process, aside from in
mature areas like hash-based signatures where we have a lot of research
that we can draw on. For me, the rest of the field is in too much of a
state of flux, and the expertise that might otherwise be available is
(rightly) focussed on the NIST process with its (rightly) much longer

I would welcome a CFRG-wide decision to look at "an interoperability
specification for PQ algorithms to be used in a hybrid context" as you put
it. But that's not the same as looking at PQ algorithms. Let's not
conflate/confuse them.

Further comments/discussion very welcome - as always.



On 22/03/2017 12:34, "William Whyte" <> wrote:

>Hi Kenny,
>I didn't see that mail, thanks for forwarding.
>Personally I find Ben's position more convincing:
>>> The other way round does neither: Just because there are Internet
>>>Drafts specifying
>PQ-safe key exchange algorithms, this does not mean they have to be
>implemented. Anyway,
>existing implementations are indications for the need of PQ-safe key
>exchange algorithms.
>Therefore, in my view, it is reasonable to specify Internet Drafts for
>PQ-safe key exchange algorithms suitable for implementation.
>There are organizations that need to plan for a migration now in order to
>properly manage risk and that can't wait for the NIST process to
>complete. Providing an interoperability specification for PQ algorithms
>to be used
> in a hybrid context allows these organizations to start development and
>prototype deployment.
>I'm not sure the "current CFRG approach" has been formally decided on;
>it's more "what CFRG happens to be doing at the moment". If CFRG members
>see value in specifying a wider range of algorithms, the CFRG approach
>can be
> changed.
>On Wed, Mar 22, 2017 at 8:26 AM, Paterson, Kenny
><> wrote:
>This e-mail I sent back on 15th March laying out the CFRG leadership's
>current position on post-quantum algorithms does not appear to have made
>it into the CFRG archive and perhaps did not make it to the list. It seem
>pertinent to send it again, in view of an on-going discussion on the list.
>On 15/03/2017 08:23, "Paterson, Kenny" <> wrote:
>>Hi Benjamin,
>>Full disclosure: I am involved in one proposal being prepared for the
>>Wearing my CFRG co-chair's hat, I would say that Watson is correct, in
>>sense that the current CFRG approach is to define RFCs for a few
>>relatively mature post-quantum primitives, such as hash-based signatures,
>>but to wait for the results of the NIST process for everything else.
>>The NIST process is going to run for many years - it just started, and is
>>slated at 5-7 years. It will entail a significant effort by the research
>>community, which is right and proper given the current state of the
>>On 15/03/2017 02:38, "Cfrg on behalf of Watson Ladd"
>>< on behalf of
>> wrote:
>>>On Tue, Mar 14, 2017 at 10:31 AM, Tams, Benjamin
>>><> wrote:
>>>> Hi John,
>>>>> Good that CFRG starts some more detailed discussion on PQC. It makes
>>>>> to support post-quantum key exchange for use cases that need
>>>>> confidentiality (15 years). For other use cases I think it can wait
>>>>> PQC key exchange algorithms has been thoroughly evaluated and
>>>>> standardized. If implemented now, it should be used in addition to
>>>>> just like Google has done with their experimental New Hope
>>>> I absolutely agree with your view on the subject. Especially for those
>>>> cases where the attack scenario "collect today, decrypt tomorrow" is a
>>>> we should start thinking of PQ-safe key exchange methods in time. Even
>>>> they eventually turn out to be insecure; we can now combine them with
>>>> classical key exchange algorithms. We have nothing to lose.
>>>> There is already IETF work addressing PQ-security in Internet
>>>>protocols, e.g.
>>>> IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuite for
>>>> On the other hand, there is (to my knowledge) no specification for a
>>>> patent-free key exchange algorithm suitable for implementation. In
>>>>fact, in
>>>> only NTRUEncrypt is specified but is subject to patents.
>>>> A possible first step is that CFRG creates an Internet Draft. In fact,
>>>> the algorithm New Hope has already been implemented as a plugin for
>>>> strongSwan (IPSec implementation for the Linux kernel)
>>>> So why do we not start with a draft for which the above implementation
>>>> serve as a reference implementation?
>>>Why should we preempt the current NIST postquantum standardization
>>>> Kind regards,
>>>> Benjamin
>>>> _______________________________________________
>>>> Cfrg mailing list
>>>"Man is born free, but everywhere he is in chains".
>>>Cfrg mailing list
>Cfrg mailing list