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

["Mark D. Baushke" <[e-mail]>]

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.

> 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