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