Re: [Cfrg] Postquantum cryptography in IETF protocols

Aaron Zauner <azet@azet.org> Tue, 21 March 2017 23:27 UTC

Return-Path: <azet@azet.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30BA129407 for <cfrg@ietfa.amsl.com>; Tue, 21 Mar 2017 16:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org
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 u89uma2rCNGT for <cfrg@ietfa.amsl.com>; Tue, 21 Mar 2017 16:27:33 -0700 (PDT)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F3A128708 for <cfrg@irtf.org>; Tue, 21 Mar 2017 16:27:33 -0700 (PDT)
Received: by mail-wm0-x22d.google.com with SMTP id 196so5276950wmm.1 for <cfrg@irtf.org>; Tue, 21 Mar 2017 16:27:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=FIDFWbna2VTQFEG/CSRuLsoQjKSj4yQZa+qrdGyBth0=; b=ECCGaYgjGdbNnK4NyjD/L5N0mx84YUtVBHRmqTiGuT7UNhUoLHoqbuPJeatnRcjT3v cs78MuCrJOU2dWMbSPB1uGPo18F/d+MC2lGXlaWU9bEPf8ho7p5JbV1Jw2ypkIsnkNLy ddfPNREcZfQ6gVz+cCvycA0nbOOBhu9dG9+FQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=FIDFWbna2VTQFEG/CSRuLsoQjKSj4yQZa+qrdGyBth0=; b=crO4VblSVx1HW3Msbkt20W86CFlkZO4ISpmVbh0JimkKcFijRRVHff0EYy2Os24pUm 1zD/JY4D7OoENviUaq4TvZ8Z4t0YTk2aZDr2fF1gTI6Vnxh8lPH0cfWlx8K1E2hrhO1L cqPGw4DvN2fO0agEKbmQM0E9fifvtyVCrPIuem1H+OFcyEso3FtL1nVCpszMLDcyOl5S 8AAnZ5eEL/HNNqR0Qv3NAsdoaQhCElWt37UBxNXdfvBOzvs32axhO3/HDtxEJxjTSFJx 1TlyaScutZY+wWjcAZi373yF6yQMouO7MU9PQc2IY2JHR0lmVIHiPbf5EzhKeYrZaEQR a/Jg==
X-Gm-Message-State: AFeK/H1qVQjhR+klJk1vf9ZfrYObs/D+JSp90lC1wMtB06Zeh26s4smnJRLlzhRIGJH5Tg==
X-Received: by 10.28.95.85 with SMTP id t82mr5203215wmb.107.1490138846991; Tue, 21 Mar 2017 16:27:26 -0700 (PDT)
Received: from [192.168.3.194] ([217.5.149.10]) by smtp.gmail.com with ESMTPSA id t63sm19355705wme.16.2017.03.21.16.27.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Mar 2017 16:27:26 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_36B5F71F-9E8D-44A7-A0D0-B38CF0D6B33B"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Aaron Zauner <azet@azet.org>
In-Reply-To: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de>
Date: Wed, 22 Mar 2017 00:27:16 +0100
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Message-Id: <51780B9E-8BE5-493F-8338-AB3E80E9BFEC@azet.org>
References: <78B0B91A8FEB2E43B20BCCE1326131812D6B62F6@mail-essen-01.secunet.de>
To: "Tams, Benjamin" <Benjamin.Tams@secunet.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/xUXUnM9whaLGMETkz2v2hHWtLds>
Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2017 23:27:36 -0000

Hi,

Quick comment:

> On 14 Mar 2017, at 18:31, Tams, Benjamin <Benjamin.Tams@secunet.com> wrote:
> 
> Hi John,
> 
>> 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.
> 
> I absolutely agree with your view on the subject. Especially for those use
> cases where the attack scenario "collect today, decrypt tomorrow" is a threat,
> we should start thinking of PQ-safe key exchange methods in time. Even if
> 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
> 
> https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03
> https://tools.ietf.org/html/draft-whyte-qsh-tls13-03
> 
> On the other hand, there is (to my knowledge) no specification for a PQ-safe
> patent-free key exchange algorithm suitable for implementation. In fact, in
> https://tools.ietf.org/html/draft-whyte-qsh-tls13-03
> 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)
> 
> https://github.com/strongswan/strongswan/tree/master/src/libstrongswan/plugins/newhope
> 
> So why do we not start with a draft for which the above implementation can
> serve as a reference implementation?

NewHope has been implemented in Tor and also in Chrome for testing purposes. As for StrongSwan: they implement quite a lot. There's also a NTRU IKE implementation available in StrongSwan (https://wiki.strongswan.org/projects/strongswan/wiki/NTRU). Just because there's an implementation of something doesn't necessarily warrant work on an internet draft/standard. To me PQC is quite a new field and security boundaries are not as established as they're for say symmetric or public key cryptography (someone correct me if I've missed major news in that area). BTW there was a recent paper with some "improved" attacks on NewHope (it doesn't break the scheme, they just recommend more conservative parameter choices) - https://eprint.iacr.org/2017/221


Aaron