Re: [Cfrg] big-endian short-Weierstrass please

[Tony Arcieri <[e-mail]>]

On Tue, Jan 27, 2015 at 7:41 AM, Dan Brown <[e-mail]> wrote:

> I appreciate that currently, TLS is thinking to use Curve25519 a named
> curve, specified by an OID, and then determine all point representations,
> including the internal used ones used in the KDF and signatures, based on
> the named curve.  That should work too for TLS and any easily updatable
> software.
>
>
>
> But I wonder if there are any old implementations of the standards I
> listed above, that accept generic specified short Weierstrass curves, but
> lock together the KDF and raw ECDH operations.  Users stuck with such
> implementations couldn’t gain _*all*_ the benefits of Curve25519, side
> channel resistance or whatever, but surely there’s some residual benefits
> for them to use Curve25519 with a generic representation: maybe the
> rigidity Curve25519, or interoperability with other users with the
> newfangled software, not to mention the blessing of the collective wisdom
> of CFRG.
>

I *strongly* oppose this entire proposal.

For D-H, Montgomery x-coordinates are way less error prone. Field
arithmetic bugs in Weierstrass implementations are common, and furthermore
old Weierstrass implementations that need to interoperate with Montgomery
x-coordinate representation can convert to Weierstrass. For signatures we
should be using Edwards for similar reasons.

My employer is doing something of this nature I can't disclose and it is
working quite well for us. That is just my personal opinion: I am not
speaking on behalf of my employer.

If you accept that we should be using Montgonery x-coordinates and Edwards
group elements to represent public keys (for D-H and signatures
respectively), then we get to djb's recent arguments that big endian is
more error prone.

Big-endian short-Weierstrass is the the most error-prone representation we
could possibly use, and legacy implementations can easily still use more
modern formats on the wire then convert to the representation they
implement natively.

-- 
Tony Arcieri