more change on Curve25519 ECDH

[NIIBE Yutaka]

Hello,

Thanks a lot for your reply.  My brain was almost overheated by
considering the corner cases.  I realize that E-mail interactions cool
downs my brain effectively, because... perhaps, English is the second
language (or it's not math or programming language, either) for me.

I understand that NaCl API is clever.  While its name is
"crypto_scalarmult" and I had an impression as if it were scalar
multiplication for a point on the curve, actually, it allows inputs
not on the curve and it does applying X0 function and tweaking bits
under the hood.

In our case of libgcrypt, we keep the function _gcry_mpi_ec_mul_point
as scalar multiplication for a point.  We extend ECDH to allow input
not on the curve for X25519.  In libgcrypt, the flag of
PUBKEY_FLAG_DJB_TWEAK is explicit to ask applying X0 function and
tweaking bits.  And we check the result of ECDH function of
ecc_decrypt_raw.

Those are small differences, but that's important.  Well, it is
important for me to learn these things.  :-)

On 04/13/2016 01:26 AM, Werner Koch wrote:
>> @@ -1394,7 +1394,13 @@ ecc_encrypt_raw (gcry_sexp_t *r_ciph, gcry_sexp_t
> 
>> +    if (_gcry_mpi_ec_get_affine (x, y, &R, ec)
>> +        && !(flags & PUBKEY_FLAG_DJB_TWEAK))
>>        log_fatal ("ecdh: Failed to get affine coordinates for kdG\n");
> 
> Instead of calling log_fatal, which terminates the process, we would
> better return an error.
[...]
> Ditto.
> 
> What do you think of such a change?

Yes, I think that it's better to return an error.  Because libgcrypt
is a library and there is a possibility it happens with invalid input,
it's good to return an error.

I'll change ECDH functions return an error for invalid input.
--