Re: [Cfrg] Chopping out curves

Alyssa Rowan <akr@akr.io> Fri, 17 January 2014 14:03 UTC

Return-Path: <akr@akr.io>
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 4E7D01AE0C4 for <cfrg@ietfa.amsl.com>; Fri, 17 Jan 2014 06:03:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZQ9lAmeyGWJ for <cfrg@ietfa.amsl.com>; Fri, 17 Jan 2014 06:03:52 -0800 (PST)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9811ADFD2 for <cfrg@irtf.org>; Fri, 17 Jan 2014 06:03:52 -0800 (PST)
Received: from [10.66.231.136] (94.197.120.244.threembb.co.uk [94.197.120.244]) by entima.net (Postfix) with ESMTPSA id 3CAD76034A for <cfrg@irtf.org>; Fri, 17 Jan 2014 14:03:38 +0000 (GMT)
User-Agent: K-9 Mail for Android
In-Reply-To: <20140117124159.GA9258@netbook.cypherspace.org>
References: <CACsn0cmJX2begH0q8vOUZhP2t3CFo_2Ad71Neke4EKejoYCPRg@mail.gmail.com> <CAGZ8ZG1qF4ba3ogjHQnMwgXV+0Fj7eR44QdvuSw3GYBvNVFZBA@mail.gmail.com> <c406386b6fc67d11332141423f2f0f40.squirrel@www.trepanning.net> <CACsn0c=Eh1J81JHq=u8WsTtVK4HAJDghyisTZnM6U61jdr2KUQ@mail.gmail.com> <20140117011414.GA3413@netbook.cypherspace.org> <20140117023629.GA4435@netbook.cypherspace.org> <52D8DEC1.9060805@akr.io> <20140117124159.GA9258@netbook.cypherspace.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Alyssa Rowan <akr@akr.io>
Date: Fri, 17 Jan 2014 14:03:31 +0000
To: cfrg@irtf.org
Message-ID: <3374f0a3-9998-44e9-a052-61a4a94fe00c@email.android.com>
Subject: Re: [Cfrg] Chopping out curves
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: Fri, 17 Jan 2014 14:03:55 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Adam Back <adam@cypherspace.org> 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
>ways
>(eg new generators), I thought original idea was more to provide in RFC
>format the best rigid/NUMs curves available that people are already
>starting
>to use so they at least have a reference.
>
>Generating new curves or significantly deviating from them or their
>exiting
>parameter choices, creates our own NUMs risk, and a restart on the
>review
>process, creates something that needs to have its own (maybe
>derivative)
>name, and places CFRG in the biased editorial position of both
>generating &
>selecting...
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.

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9

iQI3BAEBCgAhBQJS2TgyGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6VkMQALEychivZZqpez8W5zR50MaL06hcxnow13wdL0Bc0oRbd/9/eb0Q
BMppG99peLBFAcOE18/rTPNom/jN13p1vU36kJKLWmFczAkXz8M8R36KU1J37aCA
gMm74V+wqp2PiIgKANBL+clrKX7/Y3FpXaz996G5zssR/o7sDEtKqZQKQqeJkYek
jrjCy8S/hKPHhayjIeey4m6cfXh1f5m4o6lcNLKbPq60kUM6eNvbvvTk9iIw4c9h
QlHZb7PlIq52p6GU74m1oTtaX6+PCCZ3TpkYu5DIU2Qgmx73ZfuF2bK9RGoBu1RU
bRyMV3FNbuYFJlW2QzzeFw18AHuKRsuz1uwDKYMR2lI/H+I6C4FOxf5PQ/ryRN7f
warviKgFmVT4sgRXOztCJ3rLB4n/cBiC3cdSRfpL/QExAUBdN656Ga3ODwPO+OaN
FGLTMJRZ3kaVRckLchVHBNB+QkgiJ5pC8NguPb20YSSd0BR94Qc+hGoAtDnue8fw
9vpmzUsGN3wcuq0+Vn7SQ2OgdId4dJh/72Se2Yr/KDnYBSBYIIO4QMOaH6phQtpZ
IJc4h92umTbZvZD0v3myBAfII4WIlJut3XFRTbuLfF2wvOrNlfQVXAtV8wKdm98H
Tt5MGYIosULN+n7qjyraNtuiwmAhG0ti/H6bUtuJJSKsueftvl5blMSm
=Sfp2
-----END PGP SIGNATURE-----