Are we ready for 1.7 ?

NIIBE Yutaka gniibe at fsij.org
Mon Apr 11 11:40:04 CEST 2016


On 04/08/2016 09:28 PM, Ian Goldberg wrote:
> On Fri, Apr 08, 2016 at 05:31:20PM +0900, NIIBE Yutaka wrote:
>> @@ -1313,7 +1314,18 @@ _gcry_mpi_ec_mul_point (mpi_point_t result,
>>           Note that we don't use Y-coordinate in the points at all.
>>           RESULT->Y will be filled by zero.  */
>>
>> -      nbits = mpi_get_nbits (scalar);
>> +      k  = mpi_copy (scalar);
>> +      if ((ctx->flags & PUBKEY_FLAG_DJB_TWEAK))
>> +	{
>> +	  nbits = mpi_get_nbits (ctx->p);
>> +	  mpi_set_bit (k, nbits - 1);
>> +	  mpi_clear_bit (k, 2);
>> +	  mpi_clear_bit (k, 1);
>> +	  mpi_clear_bit (k, 0);
>> +	}
>> +      else
>> +	nbits = mpi_get_nbits (scalar);
>> +
>>        point_init (&p1);
>>        point_init (&p2);
>>        point_init (&p1_);
> 
> Those bits you're setting and clearing are specific to the single curve
> Curve25519, but you appear to be performing those operations in a
> general function, so long as the flag PUBKEY_FLAG_DJB_TWEAK is set.
> You're positive no one will ever set that flag while using a different
> curve?

Thank you for review.  Yes, I think the flag will be used for a
different curve.  I'll fix this in next version using co-factor.

> Even past that, I disagree that "gcry_mpi_ec_mul_point" should be
> messing with the scalar that's passed in.  If I say "multiply this point
> by 3", I don't want it to multiply by 2^254 instead.  The setting and
> clearing should be done in key generation, not in the multiplication
> routine.

Thank you again.  This was my bad consideration for libgcrypt.

Now, I think that it's bad idea to change gcry_mpi_ec_mul_point.
Tweak of bits should be in key generation (including ephemeral key
generation in ecc_encrypt_raw).
-- 



More information about the Gcrypt-devel mailing list