Re: [Cfrg] Postquantum cryptography in IETF protocols

"David McGrew (mcgrew)" <> Mon, 14 November 2016 04:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F444129542 for <>; Sun, 13 Nov 2016 20:32:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 q7kJYxiKUU1q for <>; Sun, 13 Nov 2016 20:31:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 797F81295C2 for <>; Sun, 13 Nov 2016 20:31:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2324; q=dns/txt; s=iport; t=1479097918; x=1480307518; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=SBwgKPsL0orfLmxlS8Gp+ZXvH4kHj/j9mi/2oxjE3qM=; b=QYvR2iOc17974kTG566AlZmywKzLfPpzoh59ArOQOdcL/pMu9YGJCLDu a4IJCAV+LxyRwh8angFDqPrOjGGgU2DREA/p2NL3iaqva5SS5Xb8NAflb BJWcEV3y9ri3f1usyOxmYQIpT3/uCpURhTy+yceBGwvfIOpqLLdfTNaWo 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,488,1473120000"; d="scan'208";a="170752267"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2016 04:31:54 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uAE4Vsir015564 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Nov 2016 04:31:54 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 13 Nov 2016 22:31:53 -0600
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Sun, 13 Nov 2016 22:31:53 -0600
From: "David McGrew (mcgrew)" <>
To: John Mattsson <>, "" <>
Thread-Topic: [Cfrg] Postquantum cryptography in IETF protocols
Thread-Index: AQHSPjAGC6I6ScxzO02NT2r/bgN0lA==
Date: Mon, 14 Nov 2016 04:31:53 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Nov 2016 04:32:00 -0000

Hi John,

On 11/13/16, 11:13 PM, "Cfrg on behalf of John Mattsson" < on behalf of> wrote:

>Good that CFRG starts some more detailed discussion on PQC. It makes sense
>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 until
>PQC key exchange algorithms has been thoroughly evaluated and
>standardized. If implemented now, it should be used in addition to ECDHE,
>just like Google has done with their experimental New Hope implementation.

Thanks for the encouraging words, I think many people agree with you on the redundant ECDH/Lattice thing.   

There was a discussion at IETF 95 CFRG - slides at

Postquantum secure signatures are need for software/firmware/data signing; that’s an important use case where hash based signatures seem useful.



>I have noticed a lot of uncertainty in various SDOs on how quantum
>computers will affect algorithms and protocols, what needs to be done, and
>when things need to be done. I recently wrote the following FAQ for 3GPP.
>I suggest that CFRG produces something similar (but more detailed) and
>publish it at an informational document. I think a document giving PQC
>guidance to IETF WGs and users of IETF standards would be very useful.
>Cfrg mailing list