Re: [Cfrg] FourQ draft now available

David Jacobson <dmjacobson@sbcglobal.net> Sun, 25 September 2016 05:06 UTC

Return-Path: <dmjacobson@sbcglobal.net>
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 17C0F12B0B5 for <cfrg@ietfa.amsl.com>; Sat, 24 Sep 2016 22:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sbcglobal.net
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 vJamfTBeC2pg for <cfrg@ietfa.amsl.com>; Sat, 24 Sep 2016 22:06:36 -0700 (PDT)
Received: from nm21-vm3.access.bullet.mail.gq1.yahoo.com (nm21-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C55E12B036 for <cfrg@irtf.org>; Sat, 24 Sep 2016 22:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1474779995; bh=cK8tl7HG0B8V3zSs9+jv1Lvo93IDovy/DLihXp2oSKQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=nNsrQmPtef3Y3Na8Gl6hah9J7hkQGrG2odtauFltBwzhuSc69ziy2GEq9ub1V2JrltkJFsa//6HJjttgYx+hNdP4dYSytsOn0KUwnYGzVSOHP/ucqta8OwFJ7yNrf7aKCWIBlRWm+RVma4U9lnUxnUpNOsCVdhdb7E3pDM+ivJ3xeBUfJybg0klE3Si7xFBzjQh86u6IckHCg1VkmOKmoGcPqCOwNNHbHkllp5mybkv1k78Pom4qPPNYzwb4pmoEjZXxUnqmwH55OlRGH9MB4xDhBmJPlWMrZiZt+FvuoVk44tlUt7ZPIhy89tQ0ZQtSogyNi2fGwku42bK81gflNQ==
Received: from [216.39.60.168] by nm21.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Sep 2016 05:06:35 -0000
Received: from [67.195.22.119] by tm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Sep 2016 05:06:35 -0000
Received: from [127.0.0.1] by smtp114.sbc.mail.gq1.yahoo.com with NNFMP; 25 Sep 2016 05:06:35 -0000
X-Yahoo-Newman-Id: 591110.79492.bm@smtp114.sbc.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: gLzPlRQVM1lvm1w1PFAgjuK3hXK7IqLRFu.wVQtcbcydpD. f5poa1B0geGokn5WZfgnSfV90HDkpe_uFWNL_oH9masmwb8b01hS_Itw6_Lf EdOCAN.zXyp_3B4XycSdzmqqZQsc.HuUTk0JlY58xj8gTZD4NXxA8I770X2X 1TYZQ7kHYtXVnT2r41U_wxr.w26BzSa7WyMCfkMFftLibwctDa7hbdBTuaCg IxnhHIUMU1ZbFE73UU4euQhTWOa01QmZMFu.XEIrovHhzYTVw0dcklklgpH7 0eJFFlojYBSK.CSkKLyzkKBGtwEN3x4FtYBc8UFYOin17IrKSuw7x75HzO0s lJTK3AafijSLaMexLIRW8BMX4RTBMkfH.pUPu8Gfj3YCkNBftpdx1da3ClOH euXKOi.RlHBUJmHyojXMtRkYxig49yG0NVmUyOsPBgOLdq9D6nH8p3ii9Mqy 89PRoPH6y929m7vB0BhloyZj4AukCWNPhvRDbPVKDl3Wejgu1lr6r_N7b8vS MLvZYOW1fYErXtSqnvzPuqvXy2jve0Gvm07yHG13QdNm3x3jfHXkJd65Jlsx VjdtlrquslA--
X-Yahoo-SMTP: nOrmCa6swBAE50FabWnlVFUpgFVJ9Gbi__8U5mpvhtQq7tTV1g--
To: =?UTF-8?Q?Hanno_B=c3=b6ck?= <hanno@hboeck.de>, Watson Ladd <watsonbladd@gmail.com>
References: <CACsn0cnhf2MBm2uBB=-LgwJYM7_tB_3B9DHdAhvU9sZkwD4MGA@mail.gmail.com> <20160923084927.2fdaf023@hboeck.de> <CACsn0cmL3Zsww2=SZs9SVdrKx5A8k6o4dObah+4h0NX1NZfoaA@mail.gmail.com> <20160924115831.3b4a8368@hboeck.de>
From: David Jacobson <dmjacobson@sbcglobal.net>
Message-ID: <3120b0b6-d97c-23d5-dd39-edecd7fdf5e4@sbcglobal.net>
Date: Sat, 24 Sep 2016 22:06:34 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <20160924115831.3b4a8368@hboeck.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/yEIoqKtM4JFS9Xr7dpAgAP_gu-k>
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: Sun, 25 Sep 2016 05:06:38 -0000

On 9/24/16 2:58 AM, Hanno Böck wrote:
> 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.
>
I used to work in the mobile device industry.  For a long time most 
mobile devices used 2048 bit RSA with exponent 3 because it was the 
fastest thing available to verify a signature.   Security conscious 
companies adopted 2048 bit RSA with exponent 65537 for added safety.   
So I suggest that these are the reference points for deciding whether 
FourQ has a good chance of getting traction based on performance.

I find the automotive collision avoidance case quite compelling.  It 
will be challenging to verify hundreds of messages per second.

If you are worried about crypto being done in an unsafe way (for 
example, not doing necessary checks) there is a simple fix:  Supply 
working code that is safe and decently optimized.  Sometimes "reference 
code" has truly terrible performance, and is only useful as the "other 
party" in a validation setup.  (SNOW 3G is a prime example.)

To facilitate adoption, make it easy for developers to get this 
algorithm approved by their legal department.
1.  Do whatever you can to allay fears that something might be 
patented.  Just having the basic inner algorithm unencumbered is not 
enough.  it must be the case the combination of the optimized inner 
algorithm as actually implemented and all the checks required for 
safety, i.e. everything in that supplied code, is unencumbered.  I'm 
aware that some standards bodies are constrained in what the can do 
regarding patents.  But do what you can, perhaps working outside any 
standards body.
2.  Release the code under a generous minimally-constraining license 
(e.g. BSD), or put it in the public domain.

    --David Jacobson