Curve25519 ECDH with ephemeral key input O
gniibe at fsij.org
Tue Mar 1 01:06:41 CET 2016
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
* 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
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:
where the point (after decodeUCoordinate function) is not on the
I think it is OK (or it is the role) for upper layer to validate
More information about the Gcrypt-devel