Curve25519 ECDH with ephemeral key input O

[NIIBE Yutaka]

On 02/29/2016 10:17 PM, Ian Goldberg wrote:
> On Mon, Feb 29, 2016 at 01:46:07PM +0900, NIIBE Yutaka wrote:
>>   although any value of k to Curve25519(k, P) cannot produce O if P !=
>>   O (because of the tweak).
> 
> This line does not sound true to me.  If k is the order of the point P
> (or 0, for that matter?), why would Curve25519(k, P) not output O (or
> more correctly, the all-0 string)?

Sorry, I should have clarified the context.  I am talking about
Curve25519 specified in RFC 7748.  It's not only a point
multiplication of [k]P.  Because of the function decodeScalar25519(k)
which changes the bits (to be multiple of cofactor), the scalar can't
be the order of the point P.


More simply, my question is:

    When an implementation (GnuPG in our case) is offered the input of
    all-0 string as ephemeral key for Curve25519 ECDH, what should it
    do?

    The situation:

    * It can be decrypted by the recipient.
    * But it can be also decrypted by anyone.
    * It is not generated by the correct procedure.

My opinion is that GnuPG should results an error as invalid input data,
although the computation of Curve25519 itself is defined with such a
data.

I am not confident enough, because it seems for me that an
implementation of Curve25519 should not validate the input.  The second
test vector in RFC 7748 is:

   Input u-coordinate:
     e5210f12786811d3f4b7959d0538ae2c31dbe7106fc03c3efc4cd549c715a493

where the point (after decodeUCoordinate function) is not on the
curve.

I think it is OK (or it is the role) for upper layer to validate
the input.
--