Re: [Cfrg] Curve manipulation, revisited

Michael Hamburg <mike@shiftleft.org> Mon, 29 December 2014 18:34 UTC

Return-Path: <mike@shiftleft.org>
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 D99521A87EA for <cfrg@ietfa.amsl.com>; Mon, 29 Dec 2014 10:34:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.555
X-Spam-Level: *
X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-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 YU5pFedygfHl for <cfrg@ietfa.amsl.com>; Mon, 29 Dec 2014 10:34:49 -0800 (PST)
Received: from aspartame.shiftleft.org (199-116-74-168-v301.PUBLIC.monkeybrains.net [199.116.74.168]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1961A8AE6 for <cfrg@irtf.org>; Mon, 29 Dec 2014 10:34:48 -0800 (PST)
Received: from [192.168.1.117] (unknown [192.168.1.1]) by aspartame.shiftleft.org (Postfix) with ESMTPSA id 14DE53AA12; Mon, 29 Dec 2014 10:32:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shiftleft.org; s=sldo; t=1419877964; bh=qVvagkcA7m7KLSgiCNSDtR8smGHOMVud8tmAbYE89M0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=X1b6MWlN5X6Re+8GQMSTFCzuWOb2JAWpTSNpEuVhz3r6mVR0SGkeAE9pBJJknXNM0 ovtmlA1Y61ZOoBafTNnoYwpK7HoK2dg7S42mucgNAniqEB08PvIzHsgPR4K+equAfn BthRsXRpuQohrZPpXvwUALdHlquNEz0S+ZLTIvAA=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2064\))
From: Michael Hamburg <mike@shiftleft.org>
In-Reply-To: <CA+Vbu7zO3OatbC+cXiV58hvJCuqiTYvnsSuyopDXum4qBX54fw@mail.gmail.com>
Date: Mon, 29 Dec 2014 10:34:45 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <EBD3350E-93CA-4D85-91C0-560D17187572@shiftleft.org>
References: <CAMfhd9W684XMmXn3ueDmwrsQ_ZdiFG+VqYLxkvs7qDwiJdpk6w@mail.gmail.com> <1725646678.805875.1419539885135.JavaMail.yahoo@jws100115.mail.ne1.yahoo.com> <CAMfhd9Ua5fFZk46Xx1AN2VgyJ=Yng6fnO8aN-_ZfzXQn0Xbxhg@mail.gmail.com> <CA+Vbu7zqFcu8d1053mZ_eEm0q=np6T3snSQ4rfY0k1-4hBVDsA@mail.gmail.com> <CAMfhd9XEqMwFzJ4sK4aHGbke6REZb26uaEEv9gbM5v_goDzwUA@mail.gmail.com> <CA+Vbu7zO3OatbC+cXiV58hvJCuqiTYvnsSuyopDXum4qBX54fw@mail.gmail.com>
To: Benjamin Black <b@b3k.us>
X-Mailer: Apple Mail (2.2064)
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/tsm6F-ijDDzcIEz85R8pS2yhIKs
Cc: Adam Langley <agl@imperialviolet.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Curve manipulation, revisited
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, 29 Dec 2014 18:34:50 -0000

> On Dec 29, 2014, at 9:14 AM, Benjamin Black <b@b3k.us> wrote:
> Had Dan been insisting that ladders be _allowed_ then I would agree with you, as I have said the same (in the line just before the part you quoted, even). What Dan said is that single-coordinate ladders are _required_.

[…]

> My point was that space/time trade-offs like that seem to be acceptable or unacceptable to Dan depending on what is being argued.

That’s because Dan has been arguing the opposite of what you claim he’s arguing.

You claim he said that only one implementation strategy — ladders —is acceptable.  But in fact, he’s been arguing that the curve/encoding/protocol should be chosen so that multiple implementation strategies — ladders, combs, whatever — will be possible.

That way, an implementor can decide what trade-offs are acceptable for his or her own implementation.  And if we make an especially good choice of curve/encoding/protocol, most of those trade-offs can be good choices instead of pitfalls.

— Mike