Re: [Cfrg] Curve manipulation, revisited

On Mon, Dec 29, 2014 at 1:59 PM, Benjamin Black <b@b3k.us> wrote:
> 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.

I don't see how this quote supports your reading exclusively. In
particular, when looking at other messages to the list from DJB, I see
the position Mike describes.

RFC 6080, and the Suite B implementors guide don't describe many
common optimizations. Are these "not allowed"?

We can and should blame the implementor for security flaws. But when
we don't provide enough guidance in standards to avoid flaws, and make
the result overly complex in ways that invite errors, we're
responsible.

I also don't see why this matters: now that Montgomery x form and
complete coordinates for signatures are being used, there isn't a
difference between the rival proposals on this point.

Sincerely,
Watson Ladd

>
>
> b
>
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin