Re: [Cfrg] Curve manipulation, revisited

[Benjamin Black <[e-mail]>]

On Mon, Dec 29, 2014 at 10:34 AM, Michael Hamburg <[e-mail]>
wrote:

>
> > On Dec 29, 2014, at 9:14 AM, Benjamin Black <[e-mail]> 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