Re: [Cfrg] Chopping out curves

Alyssa Rowan <> Fri, 17 January 2014 14:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4E7D01AE0C4 for <>; Fri, 17 Jan 2014 06:03:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kZQ9lAmeyGWJ for <>; Fri, 17 Jan 2014 06:03:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8B9811ADFD2 for <>; Fri, 17 Jan 2014 06:03:52 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 3CAD76034A for <>; Fri, 17 Jan 2014 14:03:38 +0000 (GMT)
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Alyssa Rowan <>
Date: Fri, 17 Jan 2014 14:03:31 +0000
Message-ID: <>
Subject: Re: [Cfrg] Chopping out curves
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: Fri, 17 Jan 2014 14:03:55 -0000

Hash: SHA512

Adam Back <> wrote:
>>Regarding the t25519 basepoint, the argument for using the ed25519
>>basepoint is that it's already out there and thus already rigid, but
>>yes, it is ugly.
>I'm not sure if we should be going as far as generating new curves, or
>significantly tweaking choices in the existing curves in incompatible
>(eg new generators), I thought original idea was more to provide in RFC
>format the best rigid/NUMs curves available that people are already
>to use so they at least have a reference.
>Generating new curves or significantly deviating from them or their
>parameter choices, creates our own NUMs risk, and a restart on the
>process, creates something that needs to have its own (maybe
>name, and places CFRG in the biased editorial position of both
>generating &
There are arguments in favour of both the existing or a new basepoint for t25519 (which is what I'll call the twisted Edwards representation of Curve25519 used in Ed25519, as I'm not sure it actually has a name of its own?).

Keeping the same basepoint for t25519:
• Preexisting
  - No confusion about where it came from
  - Routines already out there
  - We should perhaps focus on documenting what's in use
• Clear link to Curve25519; conversion?

Generating a new basepoint for t25519:
• Elegant; we can select minimum y that satisfies SafeCurves criteria
  - What advantage, really, would that give in implementation?
  - Is it worth any perceived benefit?
  - Absolute rigidity would be critical to avoid potential manipulation concerns
• Conversion... problematic
  - Is that actually a disadvantage?
  - Goes back to the "dual use key" question, I suppose...
• Reverification necessary, I think.
  - New basepoint → new prime order → new primality tests for SafeCurve script? (Damn. They're the expensive part.)
  - Independence: would have to ask Tanja & djb to double-check our results externally
  - Would probably cause extra delay

Anyone's clearly free to do so. Whether we *want* to do it is another question.

On balance I have to say, I think I prefer keeping the basepoint Ed25519 already uses for t25519, but it's not a strong preference. If we do change it, we do need to dot the i's and cross the t's, so to speak.

- --
Version: APG v1.0.9