Re: [Cfrg] Post Quantum (was Re: Minimum required work force for additional curve)

Simon Josefsson <simon@josefsson.org> Mon, 02 March 2015 19:38 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099961A892E for <cfrg@ietfa.amsl.com>; Mon, 2 Mar 2015 11:38:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 flvhzQd2KdKM for <cfrg@ietfa.amsl.com>; Mon, 2 Mar 2015 11:38:18 -0800 (PST)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4B51A1BA5 for <cfrg@irtf.org>; Mon, 2 Mar 2015 11:38:17 -0800 (PST)
Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:1db3:13ed:7278:5ac4]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t22Jc61I014590 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 2 Mar 2015 20:38:07 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Watson Ladd <watsonbladd@gmail.com>
References: <CACsn0cmjp6oKYYC5G7J3q_u9h7PtRDMQakg2sXwt4aX-tfLU0g@mail.gmail.com>
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
X-Hashcash: 1:22:150302:cfrg@irtf.org::bb3Ubn0jO6xh2J8W:DwQZ
X-Hashcash: 1:22:150302:watsonbladd@gmail.com::wjVeVVPk1svVOvi1:tYU2
Date: Mon, 02 Mar 2015 20:38:05 +0100
In-Reply-To: <CACsn0cmjp6oKYYC5G7J3q_u9h7PtRDMQakg2sXwt4aX-tfLU0g@mail.gmail.com> (Watson Ladd's message of "Mon, 2 Mar 2015 08:21:53 -0800")
Message-ID: <87vbijxk9u.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.98.6 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/MS6AKrcCYui8R97JlXdAS9R3l8w>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Post Quantum (was Re: Minimum required work force for additional curve)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2015 19:38:20 -0000

Watson Ladd <watsonbladd@gmail.com> writes:

> On Mon, Mar 2, 2015 at 3:25 AM, Simon Josefsson <simon@josefsson.org> wrote:
>> Kurt Roeckx <kurt@roeckx.be> writes:
>>
>>> Since I think this hasn't been clearly asked and that it might
>>> explain the answer on the other questions asked, I'm guess I'll
>>> just ask it myself:
>>>
>>> Assuming other than the 128 WF curve we only add 1 other curve,
>>> what is the minimum WF it should have?
>>
>> I believe the focus on power-of-two work factor comparisons for
>> asymmetric schemes is harmful.  It makes people jump to the conclusion
>> that asymmetric schemes share the commonly-believed property that
>> symmetric schemes have: that adding another bit in the key space doubles
>> the work factor.  This focus also leads to confusing "algorithm pairing"
>> ideas.
>>
>> The concept of work factor is useful though.  I don't see how humans
>> will ever do > 2^100 operations using today's non-quantum-technology.
>> Thus, to me, a work-factor of 2^100 is sufficient to address our needs.
>> And at that level, I would prefer having multiple options.
>
> Why is this better? Is it so that if one goes down we have another?

I have two reasons.  The first is to enforce algorithm agility in each
of the respective areas of protocol specifications, implementations and
deployments.  If there aren't two comparable algorithms that serve a
similar purpose, people take shortcuts in each of the areas that usually
end up bites us later on.  The second is to allow for slow migration if
weaknesses is found in one of the algorithms.  Even when new
cryptographic techniques are developed, it takes time to mount them on a
particular algorithm.

>> I could live with recommending Curve25519 and some significantly larger
>> curve like Ed448-Goldilocks if we can't get consensus on anything more
>> reasonable (like two curves at 2^100-2^130 work factor), but it will
>> lead to wasting energy computing the Ed448 operations where cheaper
>> (energy-wise) alternatives would suffice.
>>
>> If we want significantly stronger alternatives to >~2^100 work factor
>> solutions, I would prefer recommending solutions that withstand quantum
>> technology attackers -- I believe there are solutions in that space.
>
> There are various proposals, some rather old and well-implemented like
> NTRU, some old and well understood like McEliece, and some exotic
> things like Ring-LWE and isogeny volcanoes. Post-Quantum cryptography
> has been brought up here a number of times, although there are some
> problems:
>
> -Most schemes have enormous public keys. Those that don't have
> structure that helps cryptanalysis, and in some cases there is some
> low-hanging fruit to pluck. Parameter choices can become trickier.
> -Implementation availability and quality. This is solvable.
> -Different problems support signatures and encryption.
>
> We can deal with the last 2, but the first one is really something
> where more research is required.

It would be useful to use some protocols that is ameanable to rapid
prototyping with good extension frameworks as guinea pigs for these
constructs -- the sooner we get some real usage, the sooner parameter
choice, algorithms and specifications will improve.  Maybe the XMPP
community wants to play with another idea for end-to-end secure chat.

/Simon