Re: [Curdle] AD Review of: draft-ietf-curdle-ssh-curves-04.txt

[Eric Rescorla <[e-mail]>]

On Fri, May 5, 2017 at 2:16 PM, Mark D. Baushke <[e-mail]> wrote:

> Hi Eric,
>
> Eric Rescorla <[e-mail]> writes:
>
> > Document: draft-ietf-curdle-ssh-curves-04.txt
> >
> > TECHNICAL
> > S 2.
> >
> >    The methods are based on Curve25519 and Curve448 scalar
> >    multiplication, as described in [RFC7748].  Private and public keys
> >    are generated as described therein.  Public keys are defined as
> >    strings of 32 bytes for Curve25519 and 56 bytes for Curve448.
> >    Clients and servers MUST fail the key exchange if the length of the
> >    received public keys are not the expected lengths, or if the derived
> >    shared secret only consists of zero bits.  No further validation is
> >    required beyond what is discussed in [RFC7748].
> >
> > Is any other validation specified? Maybe I'm missing it, but I don't
> > see any.
>
> Hmmm... When I read it, I was under the impression that this was
> referencing the concept of batched verification via the referenced via
> the [goldilocks] paper http://eprint.iacr.org/2015/625.pdf reference in
> RFC 7748. It is possible that my reading is flawed.
>
> I am willing to consider alterations to the text to make it better if
> you have something in particular to propose.


Hmm.. Mostly, I'm just trying to figure out what this document is saying,
because it just doesn't seem clear. What is it you think people should
do?

With that said, TLS just specifies:

   For X25519 and X448, implementations SHOULD use the approach
   specified in [RFC7748] to calculate the Diffie-Hellman shared secret.
   Implementations MUST check whether the computed Diffie-Hellman shared
   secret is the all-zero value and abort if so, as described in
   Section 6 of [RFC7748].  If implementers use an alternative
   implementation of these elliptic curves, they SHOULD perform the
   additional checks specified in Section 7 of [RFC7748].

-Ekr


> S 2.1. IMPORTANT:
> >    other side’s public key and the local private key scalar.  The 32 or
> >    56 bytes of X are converted into K by interpreting the bytes as an
> >    unsigned fixed-length integer encoded in network byte order.  This
> >    conversion follows the normal "mpint" process as described in section
> >    5 of [RFC4251].
> >
> > It appears you are specifying the opposite encoding from RFC 7748 which
> > says:
> >
> >    or GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, in
> >    little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... +
> >
> > First, I want to confirm that this is in fact true and that I'm not
> > missing something. Second, if it's not true, this needs to be called out
> > in big letters.
>
> I regret that I did not do anything to implement Curdle448 myself.
>
> I suspect that only Aris or Simon will be able to be authoritative on
> this set of paragraphs.
>
> >
> >
> > EDITORIAL
> >    Curve25519 provide strong security and is efficient on a wide range
> >    of architectures, and has properties that allows better
> >    implementation properties compared to traditional elliptic curves.
> >    Curve448 with SHA-512 is similar, but have not received the same
> >
> > has not received
>
> Good catch, I have incorporated this change into my copy of the
> document. I will publish an update after more folks have commented on
> the points you raised.
>
>         -- Mark
>