Re: [Cfrg] A draft merging rpgecc and thecurve25519function.

David Rufino <> Mon, 05 January 2015 18:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CD8D81A879C for <>; Mon, 5 Jan 2015 10:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OqXUCP7aKG9O for <>; Mon, 5 Jan 2015 10:34:51 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F22D1A8789 for <>; Mon, 5 Jan 2015 10:34:51 -0800 (PST)
Received: by with SMTP id hy4so8554162vcb.2 for <>; Mon, 05 Jan 2015 10:34:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N6EbjGlo3fnyd+6F4aR1X0Wl69nZiXvXPoaiqzVFu3I=; b=ME1nXYrtLYTNLQHTBaPmaWFtbiTa7oYfc5/SYFqqulQ14uHP5UGH+eWPCMqGOCzCAL ylEX8zDORX6tz01gMewICzxJhNnYjLDRp66v7TRRfGnrbFJ6hKuXQHH8piQKhb0V41RU 8iFb4CdAX2n1sBvwNG0xlu+ks0mMr574oxKzIrb+ZxS+EHFC4k6k6spNpHo+ApOmv+0e +CtgDhQM6mMPJj2zJMRdfrSQIcA3iLQLakQ3DiApyAY50MiQWv8YOFQuNM+Fxh1iSi2S KLMrugiylW1q7ZX3OBg29KDV5+D9JRva1i3God46Qm3zvBdGNXGgOgxqnz5UPfOnneK/ qogw==
MIME-Version: 1.0
X-Received: by with SMTP id v5mr58770518vcj.27.1420482890464; Mon, 05 Jan 2015 10:34:50 -0800 (PST)
Received: by with HTTP; Mon, 5 Jan 2015 10:34:50 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Mon, 05 Jan 2015 18:34:50 +0000
Message-ID: <>
From: David Rufino <>
To: Tanja Lange <>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [Cfrg] A draft merging rpgecc and thecurve25519function.
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Jan 2015 18:34:54 -0000

Ok, thank you (and Watson) for pointing that out. So presumably
modifying one of draft-black/draft-turner/draft-cfrgcurve to use the
montgomery-style NUMS procedure, which will generate curve25519 at
WF128, should satisfy everyone's requirements ?


On 2 January 2015 at 19:38, Tanja Lange <> wrote:
>>    Perhaps it's worth making an explicit decision on whether or not
>>    'rigidity' is actually a required feature. The very rough consensus
>>    appears to be 'no', because it's regarded as improbable ('alien
>>    technology') that anyone would be able to 'backdoor' the elliptic curve.
>>    In either case it appears to me that deciding this question ought to fix
>>    the curve on purely technical grounds (no -> curve25519, yes -> rpgecc)
> This would be quite a mischaracterization of X25519. The 2006 paper
> contains full justifications about every single choice made and
> X25519 is historically the first fully rigid curve (unless one includes
> Koblitz curves or other curves with very special properties which
> coincidentally limit the choice down to just one curve). Its coefficient
> A is the smallest one achieving all required properties. The reason
> that this draft finds a different (isogenous) curve is that it searches
> for the smallest coefficient d for a curve in _Edwards_ form rather
> than for the smallest coefficient A for a curve in _Montgomery_ form.
> This 'wiggle room' of choosing a curve shape cannot be eliminated
> but it's quite small. (Note that the paper introducing the NUMS curves
> had 26 curves spread over 3 levels of security, because of this and
> a similar decision of how to optimize the prime choice.)
> I don't understand why the procedure should be part of the draft
> anyways. A description of how to rigidly choose curves already
> appears in ACM-CSS 2013 [1]. This could be cited along with the
> NUMS paper as informative references in the security considerations.
> The generation method does not matter for the implementor
> Regards
>         Tanja
> [1] "Elligator: Elliptic-curve points indistinguishable from uniform
> random strings", Bernstein, Hamburg, Krasnova, Lange, ACM-CCS 2013,
> (Open Access)