Re: [Cfrg] Complete additon for cofactor 1 short Weierstrass curve?

Watson Ladd <watsonbladd@gmail.com> Wed, 04 November 2015 19:08 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD0C1B3359 for <cfrg@ietfa.amsl.com>; Wed, 4 Nov 2015 11:08:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 XvtEY-DHKUpt for <cfrg@ietfa.amsl.com>; Wed, 4 Nov 2015 11:08:53 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 F139A1B3358 for <cfrg@irtf.org>; Wed, 4 Nov 2015 11:08:52 -0800 (PST)
Received: by wijp11 with SMTP id p11so98618018wij.0 for <cfrg@irtf.org>; Wed, 04 Nov 2015 11:08:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a93QRlNQCkzMyZa5dS7LfTwGhOwNqdbpMXWdC39VLOI=; b=OrD4DA4AoWZG561FUkn3hLGH6sZH6uzDj/NAIEVhnZ7Vjrdn5VYewOU1+BPda6HWGO zfbdcgVFRTs6jSIqgytgnb1mvxaNyRzzVmSbFn7TeoIs9Va+cUJ6L3TApp1UEcwoJ2Pl UqyLvuZf6j0xLqnlOQwP8XBkoNBSDC0HlYSKLcEM/ShsY/GesUHOirawpsQ+zsY/InTT zqL+Iv/ZLyE5F+EFL/jh913mregWxIYyN2iAxkRNdnwXBhQO1qfSJPy9W1SKSVTU5MCP zV1NjngYrYgfbw1IzyJDcV6IvA9cVG/kjq0qpwlSnBZYzBu6xNfRY9C8pg1vKUnnwT/k 1wCA==
MIME-Version: 1.0
X-Received: by 10.194.142.45 with SMTP id rt13mr4060069wjb.45.1446664131388; Wed, 04 Nov 2015 11:08:51 -0800 (PST)
Received: by 10.28.101.212 with HTTP; Wed, 4 Nov 2015 11:08:51 -0800 (PST)
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5E77852@XMB116CNC.rim.net>
References: <810C31990B57ED40B2062BA10D43FBF5D21FA2@XMB116CNC.rim.net> <5483749E.1000504@dei.uc.pt> <810C31990B57ED40B2062BA10D43FBF5D23FBB@XMB116CNC.rim.net> <548613FE.8060107@dei.uc.pt> <810C31990B57ED40B2062BA10D43FBF5E76B45@XMB116CNC.rim.net> <CACsn0c=Q=idWRNLMJhntpdYx60h-0BSCvc=7z2v3tGAyt0L4Qw@mail.gmail.com> <810C31990B57ED40B2062BA10D43FBF5E77852@XMB116CNC.rim.net>
Date: Wed, 04 Nov 2015 14:08:51 -0500
Message-ID: <CACsn0cn5mDArJP9ZgMx8pknJirP=cXj3D6bjmu6is+Q3+M81aw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Dan Brown <dbrown@certicom.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/pL7PCpcvSrGO0_ivix1enjjIUkU>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Complete additon for cofactor 1 short Weierstrass curve?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
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: Wed, 04 Nov 2015 19:08:55 -0000

On Wed, Nov 4, 2015 at 12:41 PM, Dan Brown <dbrown@certicom.com> wrote:
>
>> -----Original Message-----
>> From: Watson Ladd
>> Sent: Monday, November 02, 2015 11:21 AM
>>
>> It's completely irrelevant in practice.
> [DB] Seems a tad overstated. How about: too little, too late.
>
>> Multiplying points by 4 or 8 before
>> hashing and after subtracting for equality checks produces a prime order
> group
>> without the efficiency loss inherent to these formulas.
>
> Cofactor-1 curves obviate the need for cofactor-multiplication (e.g.
> multiplying by 4 or 8). In that regard, they improve implementation-fault
> tolerance: one less thing for an implementer to get wrong - similar in
> principle to using twist-security or pseudo-randomized signatures.  The
> efficiency loss you mention is now quite a tolerable loss, due to this new
> paper.  Given the relatively tolerable efficiency, the deciding question
> should be about security.

An implementor who removes a multiplication by 4 where it matters will
get the wrong result and the keys they derive will fail to agree with
the other end. An implementor who uses incomplete formulas is not
guaranteed to notice.