invalid generated public key

[bloobird0]

Hello, thanks for your work. I wanted to play with your implementation on both a 64 bits PC and a 16bits PIC24F µC. I played with k163 curve.

On PC, it works like a charm (although it generates a public key filled with 0x00 when I build in release and works in debug) but on the PIC24F, it takes around 30s (!) to execute ecdh_generate_keys() and the final result is a public key filled with 0x00. May I have incorrectly used it so that it generates such a public key? Is the implementation supposed to work on 16bits CPUs?

[kokke]

Hi @bloobird0 and thanks for your interest in this library :)

As far as I know, the only problem would be big endianness processors, which would require you to byte-swap the const numerals, as mentioned in https://github.com/kokke/tiny-ECDH-c/issues/5 The code should be portable enough to run on 8 and 16-bit micros.

int ecdh_generate_keys(uint8_t* public, uint8_t* private) requires the private key to be a random bitvector of a certain degree (degree must be at least half the degree of the chosen curve) and will return 0 if that is not the case.

Can you please check the return value of the call to ecdh_generate_keys() when you get a public key filled with 0x00.

[bloobird0]

Hello, ecdh_generate_keys() returns 1 in this case.

   BYTE i;
    memset(&m_localPublicKey[0], 0xAA, ECC_PRV_KEY_SIZE);
    memset(&m_localPrivateKey[0], 0xBB, ECC_PUB_KEY_SIZE);
    memset(&m_sessionKey[0], 0x00, SECURE_KEY_LENGTH);

    //Generate a public/private key pair

    // Initialize and seed random number generator
    prng_init((0xbad ^ 0xc0ffee ^ 42) | 0xcafebabe | 666);

    // Alice picks a (secret) random natural number 'a', calculates P = a * g and sends P to Bob.
    for (i = 0; i < ECC_PRV_KEY_SIZE; ++i)
    {
        m_localPrivateKey[i] = prng_next();
    }
    if (ecdh_generate_keys(m_localPublicKey, m_localPrivateKey) != 1)
    {
        while (1);
    }
 }

I have changed the init value of the public key (I initialized prior with 0x00 now with 0xBB) and it seems that bytes 0 to 2 are set to 0x00. The others are unchanged at 0xBB.

The generated private key is: 0x2F, 0x46, 0x53, 0xB8... blabla... 0x60, 0x02

[kokke]

Hi @bloobird0 - did you ever get this fixed? I am wondering if I could have fixed this issue, when I fixed #10.

If possible and at your leisure, could you please try again with the updated code, and give me your feedback on this? I would love to have a success story for referral ;)