Re: [Cfrg] FourQ draft now available

Hanno Böck <hanno@hboeck.de> Fri, 23 September 2016 06:49 UTC

Return-Path: <hanno@hboeck.de>
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 3AF2112B7BC for <cfrg@ietfa.amsl.com>; Thu, 22 Sep 2016 23:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Qrj_zapDwxiQ for <cfrg@ietfa.amsl.com>; Thu, 22 Sep 2016 23:49:32 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E587C12B3D0 for <cfrg@irtf.org>; Thu, 22 Sep 2016 23:49:31 -0700 (PDT)
Received: from localhost.localdomain ([2001:2012:115:3d00:8e6b:8908:764f:9343]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Fri, 23 Sep 2016 08:49:29 +0200 id 0000000000000090.0000000057E4D079.0000414C
Date: Fri, 23 Sep 2016 08:49:27 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?= <hanno@hboeck.de>
To: cfrg@irtf.org
Message-ID: <20160923084927.2fdaf023@hboeck.de>
In-Reply-To: <CACsn0cnhf2MBm2uBB=-LgwJYM7_tB_3B9DHdAhvU9sZkwD4MGA@mail.gmail.com>
References: <CACsn0cnhf2MBm2uBB=-LgwJYM7_tB_3B9DHdAhvU9sZkwD4MGA@mail.gmail.com>
X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-16716-1474613369-0001-2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/BT6Hky4oKtyZIc4zDm96uMMFSj4>
Subject: Re: [Cfrg] FourQ draft now available
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
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: Fri, 23 Sep 2016 06:49:34 -0000

Hi,

On Thu, 22 Sep 2016 07:05:31 -0700
Watson Ladd <watsonbladd@gmail.com> wrote:

> We would like to announce draft-ladd-cfrg-4q-00, which presents a
> high-speed Diffie-Hellman key agreement based on the elliptic curve
> FourQ. 
[...]
> We hope this draft sees its way to an RFC soon.

I wonder if this is something that should really happen.

Having more choices of cryptographic constructions is imho not always
good. It has a cost: More code, more complexity, more stuff to analyze.
Therefore each new cryptographic primitive that gets introduced needs a
good justification. I'm not sure I see this here.

We just introduced curve25519/448 and many people are moving to them.
In the more or less far future we'll probably see movements to some kind
post quantum cryptography. So I only see a relatively small time window
where this curve will be used, therefore I'd like to see more
justification why we should standardize it.

From what I see the major advantage is that FourQ is supposed to be
faster than curve25519. On the flipside I see this:

   Implementations MUST check that input points properly decompress to
   points on the curve.  Removing such checks may result in extremely
   effective attacks.  The curve is not twist-secure: implementations
   using single coordinate ladders MUST validate points before operating
   on them.

From my limited understanding of ecc security this means we introduce a
new elliptic curve which is faster than curve25519, but much more prone
to implementation security flaws.

I'm not saying I'm strictly against standardizing this, but if it's
going to happen I'd like to see better justifications. Where do you see
that curve being used? Are there scenarios where the performance
improvements matter, as in "we would like to add crypto to X, but
curve25519-based crypto just isn't fast enough"? Do you see this
realistically to be used in TLS or other major protocols? Are there
other people on this list that have concrete plans to implement this in
their product/protocol?

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42