Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography

"Tams, Benjamin" <Benjamin.Tams@secunet.com> Thu, 04 May 2017 10:17 UTC

Return-Path: <Benjamin.Tams@secunet.com>
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 BA93F129568 for <cfrg@ietfa.amsl.com>; Thu, 4 May 2017 03:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 aLdzpKL2EFaH for <cfrg@ietfa.amsl.com>; Thu, 4 May 2017 03:17:35 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7EE129510 for <cfrg@irtf.org>; Thu, 4 May 2017 03:17:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 49D3F201C9; Thu, 4 May 2017 12:17:32 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjZCDasMw9iL; Thu, 4 May 2017 12:17:29 +0200 (CEST)
Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id CC1B9200AB; Thu, 4 May 2017 12:17:29 +0200 (CEST)
Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0319.002; Thu, 4 May 2017 12:17:29 +0200
From: "Tams, Benjamin" <Benjamin.Tams@secunet.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] New draft on the transition from classical to post-quantum cryptography
Thread-Index: AQHSxFyt1OhpEFxGFkCkNWaQhkLfN6Hj4WzA
Date: Thu, 04 May 2017 10:17:29 +0000
Message-ID: <78B0B91A8FEB2E43B20BCCE132613181399287CA@mail-essen-01.secunet.de>
References: <BAE7613D-D89C-4F19-8FA5-1D3BCC55DCCB@vpnc.org>
In-Reply-To: <BAE7613D-D89C-4F19-8FA5-1D3BCC55DCCB@vpnc.org>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.36.126.244]
x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10
x-g-data-mailsecurity-for-exchange-state: 0
x-g-data-mailsecurity-for-exchange-error: 0
x-g-data-mailsecurity-for-exchange-sender: 23
x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c
x-g-data-mailsecurity-for-exchange-guid: 46B80F45-DE3A-4FD2-89B1-CF5B4A9E99F8
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/SU1_-FpgVDD6c1DZ8N5F3AhIS5k>
Subject: Re: [Cfrg] New draft on the transition from classical to post-quantum cryptography
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: Thu, 04 May 2017 10:17:38 -0000

Hi Paul,

thank you for producing the initial draft. I think such a document can be very useful for
the community and individual organizations for being taken into account for properly managing 
risk in view of possible attacks by quantum computers. I briefly read over the document. 

Here are some personal comments on the organization of the document.

If the intention of the final document is to help people understand when they have to make the
transition  from classical to post-quantum cryptography, I would like to propose to set the focus 
more on what an organization should consider for deciding whether or not to go from classical to 
post-quantum cryptography. My very personal vision is to motivate the reader to consider the
following questions.

1. What if useful quantum computers arise in the short term (e.g. 0-10 years), 
middle term (eg. 10-15 years), or long term (e.g. 15-25 years)?

2. What if I use classical cryptography today, that can be broken 
by a quantum computer in the short, middle or long term?

3. When should I switch to post-quantum cryptography for digital signatures, asymmetric
encryption, or symmetric encryption? 

4. Is my application worth for being attacked by someone who can use a quantum
computer? If it is, why? (This question is already addressed in Section 5 of the draft).

Essentially, I think the intention of the document should not be to convince the reader to use
or not to use post-quantum cryptography. It should rather leave it to the reader to decide
whether or not (and if to which extent) he considers it necessary to apply post-quantum 
cryptography in his application. 

Anyway, if an organization's decision is to use post-quantum cryptography (a decision that we
should leave open), then the organization should be able to access a specification suitable for
implementation, timely. While CFRG may already specify documents for
PQ-safe digital signatures, CFRG seems to hesitate to specify something for  PQ-safe public
key encryption. It is (not just) my opinion, that the need for PQ-safe public key encryption
is much higher, though less matured. 

If we leave it open by a CFRG (or similar) document, that the reader's  decision is to use PQ-safe
public key encryption, then we should also provide a corresponding specification - a building block 
that is still missing for IETF drafts  (https://tools.ietf.org/html/draft-whyte-qsh-tls13-04). Also see 
previous posts in this forum
(https://www.ietf.org/mail-archive/web/cfrg/current/msg09087.html).

@CFRG: Still, I am happy if there are people that are willing to specify PQ-safe public key
encryption. Alternatively, I would like to consider to initiate an individual submission for such
a draft.

Kind regards,
Benjamin



-----Ursprüngliche Nachricht-----
Von: Cfrg [mailto:cfrg-bounces@irtf.org] Im Auftrag von Paul Hoffman
Gesendet: Donnerstag, 4. Mai 2017 00:27
An: cfrg@irtf.org
Betreff: [Cfrg] New draft on the transition from classical to post-quantum cryptography

Greetings again. I have just published a very, very preliminary Internet 
Draft to help people understand when they have to make the transition 
from classical to post-quantum cryptography. The draft information is 
here:

Name:		draft-hoffman-c2pq
Revision:	00
Title:		The Transition from Classical to Post-Quantum Cryptography
Document date:	2017-05-03
Group:		Individual Submission
Pages:		12
URL:        
https://www.ietf.org/internet-drafts/draft-hoffman-c2pq-00.txt
Status:     https://datatracker.ietf.org/doc/draft-hoffman-c2pq-00

This -00 is full of holes, but gives a structure for how to tell people 
about quantum computers that apply to breaking cryptographic keys, how 
to tell when those computers might become feasible, and what they need 
to think about for the transition. It most emphatically does *not* cover 
post-quantum algorithms other than to say "go look here for more info on 
that". That is, this document is about determining when people need to 
make the transition, not the algorithms to which they might transition.

Clearly, the draft needs a lot of input. Not only are there holes, there 
may be flat-out errors in it. That's why there is the strong disclaimer 
at the beginning; I am not a cryptographer, a mathematician, or a 
physicist, but I do work in fields where people are asking "should we 
even be thinking about post-quantum crypto".  Suggestions for text are 
great, suggestions that come with references are even better.

Does this seem like something that CFRG might be interested in adopting 
as an RG document? If so, I can make the next version 
draft-irtf-cfrg...; if not, I can keep this as an individual draft that 
will get published in the IETF stream instead of the IRTF stream.

--Paul Hoffman

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg