Re: [Cfrg] (flaws with Curve25519 DH function, if one does not check the output) Re: Elliptic Curves - curve form and coordinate systems

David Leon Gil <coruus@gmail.com> Mon, 16 March 2015 22:08 UTC

Return-Path: <coruus@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 349741A1BA9 for <cfrg@ietfa.amsl.com>; Mon, 16 Mar 2015 15:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 FEGfJMhtGee7 for <cfrg@ietfa.amsl.com>; Mon, 16 Mar 2015 15:08:39 -0700 (PDT)
Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (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 444831A1BA7 for <cfrg@irtf.org>; Mon, 16 Mar 2015 15:08:39 -0700 (PDT)
Received: by yhpt93 with SMTP id t93so22390731yhp.0 for <cfrg@irtf.org>; Mon, 16 Mar 2015 15:08:38 -0700 (PDT)
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=/7NnPV24lvQ8WbAqHGFgCPdmQ8ytG5Bwyb9jcWnAwTI=; b=iuloW3aQ+V7ej6yzrg+FAx75KrirXNMbpZyguXYOpW9Q+TGMnfo7+jJxPNMxFsuqBl wpNELQx0t6LyJNmnWGIUXgw6c0a3JXC9ytBD3fz2vpin/lhMfB3vZ8/dZkWxJri2w2bC P091ubisH8iX/12hvUipwtlXVc/T6EwxtkXhFhTh36soAQiczwVjGTQulLSepLZyryPh SeTPZq+MjLnNZFmCuKgNLpPWkq9yXuh3mBhecXw5p54e9GiS33IUBsxSkTF3KITLcROY jYkdq538xLjpwNpOxTJqM6cN30SK40eKLL12SguVmig+R3KKR8WjXmC1N/DcjU/ussyI 88Dg==
MIME-Version: 1.0
X-Received: by 10.236.26.138 with SMTP id c10mr65041714yha.36.1426543718756; Mon, 16 Mar 2015 15:08:38 -0700 (PDT)
Received: by 10.170.125.80 with HTTP; Mon, 16 Mar 2015 15:08:38 -0700 (PDT)
In-Reply-To: <CACsn0ck6EY1PVB39a6gTxrnxgPTY_quMRGya2jm79CsH4iLC4Q@mail.gmail.com>
References: <5501E6A5.5040608@brainhub.org> <A6F30412-8E0A-4D8D-9F26-580307B46874@shiftleft.org> <20150316002255.28855.qmail@cr.yp.to> <20150316044906.GA27479@mournblade.imrryr.org> <5506D5BB.3090700@gmail.com> <20150316135620.GC27479@mournblade.imrryr.org> <5506EF80.7010809@gmail.com> <CACsn0ck6EY1PVB39a6gTxrnxgPTY_quMRGya2jm79CsH4iLC4Q@mail.gmail.com>
Date: Mon, 16 Mar 2015 15:08:38 -0700
Message-ID: <CAA7UWsW-NGZ7PEn1iLF9r_rOxuJsntCiKVJjm56JG4yhc4U0PA@mail.gmail.com>
From: David Leon Gil <coruus@gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b673c769cf61105116f1761"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/8HWAFqDgs9s3ZtoqhGFuzG_49HU>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] (flaws with Curve25519 DH function, if one does not check the output) Re: Elliptic Curves - curve form and coordinate systems
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2015 22:08:40 -0000

On Monday, March 16, 2015, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Mon, Mar 16, 2015 at 7:58 AM, Rene Struik <rstruik.ext@gmail.com
> <javascript:;>> wrote:
>
> But let's assume that we need contributory behavior. Then simply
> returning an ignorable error code doesn't work. Instead the function
> should return 32 random bytes if computing 0, so as to avoid ignoring
> the errors.
>

I'm really inclined to think that it is better to use an encoding format
that rejects points that do not ensure contributory behavior. I don't think
that it's wise to assume that protocol designers will understand when
this is required as well as you do.

(Indeed, I'm unaware of any Curve25519 implementation that checks for this
at present...)