ECDH loads parameters as signed

Ján Jančár jancar.jj at gmail.com
Wed Oct 31 00:06:32 CET 2018


Hi,

On 30/10/2018 03:17, NIIBE Yutaka wrote:
> Hello,
> 
> Ján Jančár <jancar.jj at gmail.com> wrote:
>> while trying to get libgcrypt to do ECDH I think I came up to a bug, or
>> at least a bit of unexpected behavior.
> 
> Sorry for late response.  Frankly speaking, I don't understand what you
> try to solve.

I am trying to generate keypairs, export them (into Java via JNI), then
import them again and use them. For that an unsigned representation of
the domain parameters and key material seemed obvious.

> 
> I would agree that it might be good idea to use unsigned representation,
> if it were now the time we start writing new code.
> 
>> This means that if keys are generated, then exported into unsigned MPIs
>> from the S-exps, then again built into S-exps using the unsigned
>> notation %M, and passed into ecc_encrypt_raw/ecc_decrypt_raw, they will
>> still be considered signed if their highest bit is set.
> 
> Isn't it a thing of... "Don't do that, then."?
> 
> IIUC, your proposed change will break existing keys with
> PUBKEY_FLAG_PARAM, represented by %m (signed).  See the function
> ecc_generate in libgcrypt/cipher/ecc.c.
> 

My thinking is that when I specify %M in building the S-exp, I mean that
the MPI should be stored and interpreted in the S-exp as unsigned. Thus
gcry_pk_encrypt/decrypt and gcry_pk_sign/verify should not just choose
to re-interpret them as signed.

Will the change actually break using those keys? I applied the changes
to ECDH and tested generating a keypair with PUBKEY_FLAG_PARAM, the
public key of which is then directly passed into gcry_pk_encrypt, and it
proceeds just fine, the values of loaded domain parameters are the same.

Cheers,
Ján Jančár



More information about the Gcrypt-devel mailing list