Re: [Cfrg] FourQ draft now available

William Whyte <> Sun, 25 September 2016 16:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3182B12B252 for <>; Sun, 25 Sep 2016 09:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zKkU0vAAA6Co for <>; Sun, 25 Sep 2016 09:15:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7761E12B24A for <>; Sun, 25 Sep 2016 09:15:29 -0700 (PDT)
Received: by with SMTP id d8so25114329vka.3 for <>; Sun, 25 Sep 2016 09:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wtMIPGOOwBehbMDt4BbTT6r/KKOqybUqSmubCSBIA6I=; b=Meht0yCPyk4puFsBSWLKv1JaJtfhPWuiKoHbBIfMm1n8/fBkptkw3S+QNTGTHoUk8t +VAuvddtrNnVJ1A3qvjkNNid11kL4ec46E1NAgjX3ljZjAIzuq2yFPb6utQUO2o/OiGA qCgFvxGcEUh5AXHRiY2hDXcR+zDXK8gEYvw80=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wtMIPGOOwBehbMDt4BbTT6r/KKOqybUqSmubCSBIA6I=; b=PreBR7o96cLIj7YS6P+o+0l1pgmSrs1XlULhfbStqaAlhwwpZwbOeIbVRkdT/Y1pjN a7MUtEOMnIxReA+Rm3STpk1ofPBnJwFa6QdueimwUbFCnVlLtANH2Dj9GUiZeQM2bPXD 7heS6TTC0jOdgZudG9hJyPx+cMFKjxmMUKFj26h9J53ZuBgLGia+TtJu3n708V1rvktt tjk+2nKOp0i4tW+FrexR9pU/l5HK92k3+VaagIXAusUJsupKr4ygPsZkaO/HqhaUcy9M O0E6GUQi/eyRvb95GkKsQD2Lx5kzbX4ls71/4v1p6vuwrIpmNQdYBi3IuFRvMHct78Uc BoOw==
X-Gm-Message-State: AA6/9RlJfIsLRtCZOSQhBdm6hqJmcG6Kb0AwkAdhvyGgtE3eYDJPoQNKdxRB2u8kuCve262+KtKCWgZu1cRRHKLT
X-Received: by with SMTP id i186mr4725287vkh.127.1474820128468; Sun, 25 Sep 2016 09:15:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 25 Sep 2016 09:15:26 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: William Whyte <>
Date: Sun, 25 Sep 2016 18:15:26 +0200
Message-ID: <>
To: David Jacobson <>
Content-Type: multipart/alternative; boundary="94eb2c091528dd845f053d5751e3"
Archived-At: <>
Cc: CFRG <>
Subject: Re: [Cfrg] FourQ draft now available
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Sep 2016 16:15:32 -0000

Hi all,

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

V2V applications are unlikely to change from NIST p256 / Brainpool r256 at
this point.



On Sun, Sep 25, 2016 at 7:06 AM, David Jacobson <>

> On 9/24/16 2:58 AM, Hanno Böck wrote:
>> On Fri, 23 Sep 2016 09:46:25 -0700
>> Watson Ladd <> 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
> _______________________________________________
> Cfrg mailing list