Re: [Cfrg] FourQ draft now available

Watson Ladd <watsonbladd@gmail.com> Sun, 25 September 2016 16:09 UTC

Return-Path: <watsonbladd@gmail.com>
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 99FDE12B250 for <cfrg@ietfa.amsl.com>; Sun, 25 Sep 2016 09:09:34 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 veDbUtJjyVn4 for <cfrg@ietfa.amsl.com>; Sun, 25 Sep 2016 09:09:33 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 EB86612B24A for <cfrg@irtf.org>; Sun, 25 Sep 2016 09:09:32 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id 192so25094945vkl.2 for <cfrg@irtf.org>; Sun, 25 Sep 2016 09:09:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RtCIWVJh+t3r+DM1R4klTYC0IHUp+u4EZ1ezo9odeG8=; b=flBZNmOYK+54Pu+I+qTi/ImnYrTcLe8W5I7CHsRy6ZnlBiqGnLP8baV8PcHrBqDVYj zFVBrCqY2OBrw7W2Xmp+13y9r8mDnPQiYPFrVSxavniFIJ+WCqgpFuX/SMphxATv7ugO KxXhdmkcqn/3Ei11HKxO12VzNeR2mo0cDd64wXQXhCnHXmVG03p9TzVx1Qg1DkC+Tg5n fDYYtQAxIaNDumc9oSqjP0qTtmS2EFyIgd49H7XyUygMuwlN/t/ZbVuqJqJnfrJNeAJm T4nssI3e9bwntESEQT9DFG/kuWdod47veA+2/Qxe2eCekdTCJmsmAChzVIl71v7UO76y cJ+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RtCIWVJh+t3r+DM1R4klTYC0IHUp+u4EZ1ezo9odeG8=; b=hF80ZpRIlChQsuee1IkVwTNkqClKANF/1ivrrW7WBU3RDpaLyDKep9ok3rZDPNSYdo IP/38bcAGXtBTCfk4CRH04x8VwE69svCsUKyP9aB+/Mp4iRbcZhGL7mAXi/ifhvwsvsR xf6CEnZeBMQPt4oSXT3R49Y++lRww5GZV/2xOg+SB8fKY+3Gc5HXyNIevzQM68IZM8v1 VfzqjWYxW6kfXcr0+UC8AND/cyUM4oRIxazw/gecJifsy+rXJ4Gd0hV01nS1ZFaf8Oli Jn3X2jYa8fXHhKkqN18ih0iGpFC/HuNF6N1GbOoyqmwTGX+FdgZCaZO69HrLUyw8g9vY 7/7Q==
X-Gm-Message-State: AA6/9RklNgNpehn8De921571gS4S2mCxtHNAqx2u5+cTCuRz8GXPOrtau5pdM7q69U8PrKhUTbQEP1VeszXcWg==
X-Received: by 10.31.176.12 with SMTP id z12mr4758628vke.92.1474819771993; Sun, 25 Sep 2016 09:09:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.102 with HTTP; Sun, 25 Sep 2016 09:09:31 -0700 (PDT)
In-Reply-To: <3120b0b6-d97c-23d5-dd39-edecd7fdf5e4@sbcglobal.net>
References: <CACsn0cnhf2MBm2uBB=-LgwJYM7_tB_3B9DHdAhvU9sZkwD4MGA@mail.gmail.com> <20160923084927.2fdaf023@hboeck.de> <CACsn0cmL3Zsww2=SZs9SVdrKx5A8k6o4dObah+4h0NX1NZfoaA@mail.gmail.com> <20160924115831.3b4a8368@hboeck.de> <3120b0b6-d97c-23d5-dd39-edecd7fdf5e4@sbcglobal.net>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Sun, 25 Sep 2016 09:09:31 -0700
Message-ID: <CACsn0ckV7cJUtQNZxMP2RTvSmThvMFCqYa4onEtVKzB7pnj3vA@mail.gmail.com>
To: David Jacobson <dmjacobson@sbcglobal.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ZPpg7dsZOF5lGKjDa0wlEFW5TbM>
Cc: "cfrg@irtf.org" <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 16:09:34 -0000

On Sat, Sep 24, 2016 at 10:06 PM, David Jacobson
<dmjacobson@sbcglobal.net> wrote:
> 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.

The optimizations are patented, but not by us. Point compression
patents expired in 2008. As for the question of other patents, consult
a lawyer: there is no way to know which patents may or may not apply.

>
>    --David Jacobson
>
>
>
>
>
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.