Re: [Cfrg] FourQ draft now available

Hanno Böck <hanno@hboeck.de> Sat, 24 September 2016 09:58 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 F3E33127A90 for <cfrg@ietfa.amsl.com>; Sat, 24 Sep 2016 02:58:37 -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 kwG-wfD17m3i for <cfrg@ietfa.amsl.com>; Sat, 24 Sep 2016 02:58:36 -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 DA02712B11A for <cfrg@irtf.org>; Sat, 24 Sep 2016 02:58:35 -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; Sat, 24 Sep 2016 11:58:34 +0200 id 000000000000010D.0000000057E64E4A.00005816
Date: Sat, 24 Sep 2016 11:58:31 +0200
From: Hanno Böck <hanno@hboeck.de>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20160924115831.3b4a8368@hboeck.de>
In-Reply-To: <CACsn0cmL3Zsww2=SZs9SVdrKx5A8k6o4dObah+4h0NX1NZfoaA@mail.gmail.com>
References: <CACsn0cnhf2MBm2uBB=-LgwJYM7_tB_3B9DHdAhvU9sZkwD4MGA@mail.gmail.com> <20160923084927.2fdaf023@hboeck.de> <CACsn0cmL3Zsww2=SZs9SVdrKx5A8k6o4dObah+4h0NX1NZfoaA@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-22550-1474711114-0001-2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/Qhcqp8UlANFTysRjGUMBUTmn24M>
Cc: cfrg@irtf.org
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: Sat, 24 Sep 2016 09:58:38 -0000

On Fri, 23 Sep 2016 09:46:25 -0700
Watson Ladd <watsonbladd@gmail.com> wrote:

> One of the high-profile uses of Curve25519 is in locking the disk of
> an iPhone (do we have a flash compatible term for that yet). This
> requires a public key operation on the receipt of any push message,
> which directly impacts battery life. With IoT many more devices will
> have quiescent states, until an event happens which they need to
> quickly process.

I can understand the Apple use case, however I wonder if this is really
an issue, would like to see numbers on that (given all the things an
iphone does I'd assume a curve25519 operation isn't really on top of
the things).
I'm much more worried about your second idea - IoT. Given the
security track record of IoT I'd rather not give them something that
they can mess up easily. Reading the FourQ draft it explicitly says
that it's not twist secure and that point checks have to be
implemented. I'd rather give them something without such pitfalls, aka
curve25519 for now.

> Realistically it could be used in TLS. Plenty of little known national
> curves are. But I think a lot of applications are more demanding then
> TLS on crypto performance.

They are RFC'ed, but are they actually used?
This is actually more an example of the bloat things I'd like to avoid:
People put crypto in RFCs because of national pride ("we need our
German elliptic curves" - seriously, I heard that multiple times), not
because of technical arguments.

The FourQ case is different - there is a technical argument (speed),
but I still wonder if that's good enough to justify an RFC.


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

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