Re: [Cfrg] Postquantum cryptography in IETF protocols

"Paterson, Kenny" <> Wed, 22 March 2017 12:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06869129736 for <>; Wed, 22 Mar 2017 05:26:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.697
X-Spam-Status: No, score=-4.697 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_H2=-2.796, 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 YfGqVvlSplbG for <>; Wed, 22 Mar 2017 05:26:21 -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 C669912971E for <>; Wed, 22 Mar 2017 05:26:20 -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=Je60JljYxiqkj8+MKc1I2HDlOrSqs0iKYnnW7XiFbp0=; b=NVF9mAg/Y7ENj+8+yPkRLw3X3Fq0dPOT24aQwRRQZZ5KdiEKPFGOKknL9Wq4cc79GmR6WqYvbkndgUzPf0eL3129gC5v90xF27jKbgfVdkYisNW013kBGdt+wdVPhSJK1++16O5JgiJH/k99lxYU0CMWB+MZAWI/BeDT8YzmwqM=
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 12:26:17 +0000
Received: from ([]) by ([]) with mapi id 15.01.0977.019; Wed, 22 Mar 2017 12:26:17 +0000
From: "Paterson, Kenny" <>
To: Watson Ladd <>, "Tams, Benjamin" <>
CC: "" <>
Thread-Topic: [Cfrg] Postquantum cryptography in IETF protocols
Thread-Index: AQHSnTVJcjR350Po60+E6F5IvEbv/KGVkP8AgAtEM4A=
Date: Wed, 22 Mar 2017 12:26:17 +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; AM4PR0301MB1905; 7:BWCPwt1WH8zKmud5NbXwx8EG86vcjRWam873rEI19qq7XMBj5k6paliL1m5vok+BYPX4tAdX4tMrp5um9g8nM1L7iCAAhkun0J2LVEM+H/wuRVi85G6z2dKBbcd1RX692Xm6HSSerUnnrN4BbK+1fxyofeB3lDXvCMfJOj1274ah52+D+9uZ+w7lvCHw6pDNX5FCA2npZk54w1xZRXtcGYCDptnE2wkmh/YITlZpQIuVp66y4Cf/pKbYcECmbxqst2CWGueKZLx+azvzIPEAYBmUuKgDI2d80XGIiG3XZkIxaUSEJC0stIV3kfg0DaUwWQ+2J9P1LnjJ29vtDcaQ3w==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(24454002)(377454003)(2900100001)(102836003)(54356999)(6116002)(74482002)(3846002)(50986999)(66066001)(86362001)(76176999)(189998001)(4001350100001)(3660700001)(2906002)(36756003)(3280700002)(6436002)(122556002)(6512007)(6486002)(4326008)(53936002)(77096006)(83506001)(99286003)(6306002)(305945005)(6246003)(229853002)(561944003)(2950100002)(81166006)(38730400002)(8936002)(6506006)(8676002)(39060400002)(53546009)(42882006)(7736002)(5660300001)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1905;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
x-ms-office365-filtering-correlation-id: 27b4cb43-b72d-425b-0cc2-08d4711ea3e8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075); SRVR:AM4PR0301MB1905;
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)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:AM4PR0301MB1905; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1905;
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 12:26:17.6892 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1905
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 12:26:26 -0000


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 NIST
>Wearing my CFRG co-chair's hat, I would say that Watson is correct, in the
>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 field.
>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 long-term
>>>> 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 TLS
>>> 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