Are we ready for 1.7 ?
gniibe at fsij.org
Fri Apr 8 04:34:00 CEST 2016
On 04/07/2016 04:50 PM, NIIBE Yutaka wrote:
> I have an issue of Curve25519:
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
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:
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?):
k_list = [ord(b) for b in k]
k_list &= 248
k_list &= 127
k_list |= 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
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
More information about the Gcrypt-devel