Re: [Cfrg] Adoption call for draft-hoffman-c2pq-02

"Paul Hoffman" <> Sat, 10 February 2018 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11A54128896 for <>; Sat, 10 Feb 2018 09:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RTiAG0BKgWjG for <>; Sat, 10 Feb 2018 09:57:45 -0800 (PST)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0871C1200FC for <>; Sat, 10 Feb 2018 09:57:45 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w1AHvMDJ053360 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <>; Sat, 10 Feb 2018 10:57:23 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Paul Hoffman <>
Date: Sat, 10 Feb 2018 09:57:42 -0800
X-Mailer: MailMate (1.10r5443)
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <>
Subject: Re: [Cfrg] Adoption call for draft-hoffman-c2pq-02
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: Sat, 10 Feb 2018 17:57:49 -0000

On 10 Feb 2018, at 9:24, Rene Struik wrote:

> There is already an IETF document that caters to the need for 
> algorithm
> agility: see RFC 7696 [1]. There is no need for a document that 
> singles
> out specific subcategories of technical advances that may necessitate
> reconsideration of the security technology used.

RFC 7696 does not discuss the cases where the new mandatory-to-implement 
algorithm has a much higher cost than the one it is replacing. If the 
post-quantum algorithms being chosen have similar work factors to the 
ones they are replacing, this entire document is indeed moot. However, 
it seems likely that the chosen post-quantum algorithms will have much 
larger key sizes, signature sizes, or both and (other than AES256) will 
also be significantly slower.

> The suggested "methodology" in Section 6.1 is bound to be highly
> susceptible to misleading claims and "crystal ball" gazing of dubious
> technical stature.

Can you say why you feel that technical tests that are led by "trusted 
representatives from the cryptographic community" that is "using 
verifiable means to pick the keys to recover" would be "highly 
susceptible to misleading claims"? There is no evidence that previous 
technical tests for things like breaking short RSA keys or demonstrating 
hash collisions have been susceptible to such claims.

> Once there is something of technical nature to report, it is easy to
> convert this to an IRTF/CFRG draft and circulate this then.

But that's one of the main points of the document: there are various 
competing statements from the cryptographic community about whether or 
not there is something significant to report today with respect to 
building applicable quantum computers. We know that there are likely to 
be solid post-quantum algorithms which have the benefit of defeating 
applicable quantum computers with higher resource costs; it behooves us 
to determine when that benefit is worth that cost.

--Paul Hoffman