Re: [Cfrg] Curve manipulation, revisited

Benjamin Black <b@b3k.us> Mon, 29 December 2014 19:00 UTC

Return-Path: <b@b3k.us>
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 B6CD41A9024 for <cfrg@ietfa.amsl.com>; Mon, 29 Dec 2014 11:00:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 4RO9kxzUUehe for <cfrg@ietfa.amsl.com>; Mon, 29 Dec 2014 11:00:18 -0800 (PST)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6D51A9023 for <cfrg@irtf.org>; Mon, 29 Dec 2014 11:00:17 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id l15so22904681wiw.4 for <cfrg@irtf.org>; Mon, 29 Dec 2014 11:00:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=99RalzPeins3GwfsMj8QJvG3e4hoUk7FnN2xlbhmEIQ=; b=igKg0NKTnsZmDXBpTyNOhIcleenRqZxT7VjEDh+H7LSH2XjF3A5ec/e+6dAzp3TwiW GuvnOvgEEE4IcG7LI5MFApy/DF9q1NRAPdFLr5LDnJ9bzoSVZfkcGyQ+7e3Gdor3CUNC 5hyfx5umTFr0FAF/ligLYNaKbwVZnVJG7kYKX4+qBGEmdXg2uKAyG/3GQkKKyZ3txz/f WUhH4WkMd7URL93Zpi4Cc1jWVmYjXntxNb5pLByF9Px+aPal/3QlaVnu1AMRKhmFv1Vj txAUUpXIwkmfRPmPedVrwiunSZcvYJDLLQ485IcrCoweHqSB7Bh1qOEKJ0q1+POBFAfd F9dQ==
X-Gm-Message-State: ALoCoQlSkIk7b19AmW/xEOkfpIhm6ssT+u9gnBmoIhcSfkLAMDczk2wNmUUwnpiD+duAywQJaz6L
X-Received: by 10.180.109.45 with SMTP id hp13mr97142827wib.4.1419879616029; Mon, 29 Dec 2014 11:00:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.190.139 with HTTP; Mon, 29 Dec 2014 10:59:55 -0800 (PST)
In-Reply-To: <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> <EBD3350E-93CA-4D85-91C0-560D17187572@shiftleft.org>
From: Benjamin Black <b@b3k.us>
Date: Mon, 29 Dec 2014 10:59:55 -0800
Message-ID: <CA+Vbu7zxGm3EE7h3K2mg5WoziUf4bmjoaCAVzFgaaGsE=kLFpQ@mail.gmail.com>
To: Michael Hamburg <mike@shiftleft.org>
Content-Type: multipart/alternative; boundary=e89a8f3bae99233f61050b5f7cec
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/ul62VgIcvfz3qMQnV2ANeBg7EY8
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 19:00:20 -0000

On Mon, Dec 29, 2014 at 10:34 AM, Michael Hamburg <mike@shiftleft.org>;
wrote:

>
> > 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


I can only go on the things he puts in writing and they say the opposite.

>Rather than
>blaming the implementor, we eliminate these security failures by
>
>   * adding twist security, for both Montgomery and Edwards, and
>   * switching to single-coordinate ladders.

That is not a suggestion folks be allowed to implement the ladder if they
choose to. It is a requirement that they not be allowed to use anything
else. If they are allowed to use anything but single-coordinate ladders,
then, in his own words, we have not eliminated these "security failures"
and will be back to "blaming the implementor". If he means something else
he should say something else.


b