Re: [Cfrg] draft-ladd-safecurves-02 and draft-josefsson-tls-curve25519-03

[Robert Ransom <[e-mail]>]

On 1/11/14, Simon Josefsson <[e-mail]> wrote:
> Dear WG,
>
> The TLS document draft-josefsson-tls-curve25519 has been updated in -03
> to refer to the document draft-ladd-safecurves-02 that has been
> discussed here.  My thinking is that the list of curves that
> draft-ladd-safecurves recommends, and potentially/eventually the CFRG
> can recommend, is a good list of curves for the TLS WG to consider.
> Feedback from this group whether that thinking a good idea or not is
> appreciated.
>
> Another aspect came up when doing this.  Our draft includes details on
> public/private key representation, shared secret computation, and test
> vectors.  Would it make sense to move this to draft-ladd-safecurves
> instead?

I would put a general description of Montgomery and Edwards curves and
how to use them, along with one or two sample curves, in one document,
a description of how to use the curves in Montgomery form for ECDH in
another document, and a description of how to use the curves in
Edwards form for everything else (e.g. signatures) in a third
document.

The general-description document should contain:

* an explanation of what a Montgomery line is, and why twist security
makes it safe to use;
* point formats;
* point decompression and validation routines;
* an explanation of how to handle the power-of-2 cofactor (mainly Dr.
Bernstein's trick of generating secret keys divisible by the cofactor,
or equivalently doubling onto the odd-order subgroup);
* a secret key format;
* formulas for converting between Montgomery and Edwards form;
* an explanation of how to operate on the quadratic twist of an
Edwards-form curve, at least with non-square d; and
* presumably other things that I'm forgetting.

A Schnorr signature scheme draft should be completely independent of
Montgomery and Edwards curve documents, and e.g. compatible with the
NSA and BND curves.

>  It seems any IETF protocol would have similar requirements.  I
> cannot tell if there are per-protocol specific considerations that may
> influence this, making a generic specification difficult.  Thoughts on
> this is also appreciated.

There are many considerations specific to each cryptographic protocol
(ECDH, Schnorr signature, J-PAKE, Pedersen commitment, etc.).  These
considerations are independent of which networking protocol the
cryptographic protocol is being used in (TLS, IKE, etc.).


Robert Ransom