Are we ready for 1.7 ?

[NIIBE Yutaka]

On 04/07/2016 04:50 PM, NIIBE Yutaka wrote:
> I have an issue of Curve25519:
> 
>     https://lists.gnupg.org/pipermail/gcrypt-devel/2016-March/003734.html

There are actually two issues:

   (1) API of libgcrypt
       If it validates input for X25519 or not (if
       gcry_mpi_ec_mul_point computes X25519 or not).

   (2) How we should handle the possible attack?  Or is it considered
       to be an attack?

For (1), I think that libgcrypt API should be modified.  I'm going to
describe this below.

For (2), I think that it is GnuPG (the user of libgcrypt) which should
check/validate the input.  I'll post to gnupg-devel.

> Let me consider this (today and tomorrow), I'll check other
> implementations.

I looked through libssh and nettle.  IIUC, those use the API defined
by NaCl, crypto_scalarmult and crypto_scalarmult_base.  It is
described in the page:

	http://nacl.cr.yp.to/scalarmult.html

It computes "X25519" function defined in RFC 7748.  That is, the tweak
of scalar value is included in the computation.  In RFC 7748, it is
described as (in Python?):

    def decodeScalar25519(k):
       k_list = [ord(b) for b in k]
       k_list[0] &= 248
       k_list[31] &= 127
       k_list[31] |= 64
       return decodeLittleEndian(k_list, 255)

Currently, in libgcrypt, this tweak is done in key generation.  This
tweak of scalar value is not included in the computation of
gcry_mpi_ec_mul_point itself.  (I did implemented so, following the
Ed25519 implementation in libgcrypt, which was done before X25519
implementation.)

Even if our key generation does the tweak, I think that it is good to
also include the tweak of scalar value in gcry_mpi_ec_mul_point, so
that the routine will be compatible to crypto_scalarmult, for the sake
of least surprise by programmers.

Shall I proceed this way to modify gcry_mpi_ec_mul_point for
Curve25519?
--