ECC key generation example

The project for the application note can be downloaded from here :-

www.renesas.com/.../D6003976.html

A quick question when using the frameworks.

I can see that when i add the sf_crypto_key framework stack i get functions on it to create the key.

status = g_sf_crypto_key0.p_api->keyGenerate(g_sf_crypto_key0.p_ctrl, &private_key, &public_key);
if(status != SSP_SUCCESS)
{
__BKPT(0);
}

but that is the only function at that level.

When looking at the example project it seems like it uses the ECC functions directly. How do i get access to the instance of the ECC module to use other functions?

Hi Matt-
Try reviewing the Crypto Framework section of the SSP User Manual- section 4.1.18 (r11um0140). It provides an overview of all the crypto modules. You will see which other modules you need to use, in addition to the key module, like crypto cipher for encryption and decryption services. Let us know if this helps...

Thanks for the information, found it to be very useful.

I have another question regarding the key generation and the ECC parameters (Not sure if this is the correct place).

I have some requirements for the curve which are to use the following one from openssl (prime256v1). I have generated the parameters for this using:

openssl ecparam -name prime256v1 -out prime256v1.pem
openssl ecparam -in prime256v1.pem -noout -C

Which gives me arrays for:
ec_p_256
ec_a_256
ec_b_256
ec_gen_256
ec_order_256
ec_cofactor_256

using the example given here:
renesasrulz.com/.../ecc-create-key-sign-and-verify-sample-code

I have combined the following into the domain array:
ec_a_256
ec_b_256
ec_p_256
ec_order_256

This looks to be the correct length of bytes.

However when i look at the outputted generator array ec_gen_256 it appears to be larger than the defines set in r_ecc_api.h (ECC_256_GENERATOR_POINT_LENGTH_WORDS) 65 instead of 64.

Is there something I am missing?

I'll include the outputted and formatted arrays i have made:

uint8_t domain[ECC_256_DOMAIN_PARAMETER_WITH_ORDER_LENGTH_WORDS * sizeof(uint32_t)] =
{
/* a */
0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFC,
/* b */
0x5A, 0xC6, 0x35, 0xD8, 0xAA, 0x3A, 0x93, 0xE7, 0xB3, 0xEB, 0xBD, 0x55,
0x76, 0x98, 0x86, 0xBC, 0x65, 0x1D, 0x06, 0xB0, 0xCC, 0x53, 0xB0, 0xF6,
0x3B, 0xCE, 0x3C, 0x3E, 0x27, 0xD2, 0x60, 0x4B,
/* p */
0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
/* n */
0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xBC, 0xE6, 0xFA, 0xAD, 0xA7, 0x17, 0x9E, 0x84,
0xF3, 0xB9, 0xCA, 0xC2, 0xFC, 0x63, 0x25, 0x51
};

uint8_t generator_point[ECC_256_GENERATOR_POINT_LENGTH_WORDS * sizeof(uint32_t)] =
0x04, 0x6B, 0x17, 0xD1, 0xF2, 0xE1, 0x2C, 0x42, 0x47, 0xF8, 0xBC, 0xE6,
0xE5, 0x63, 0xA4, 0x40, 0xF2, 0x77, 0x03, 0x7D, 0x81, 0x2D, 0xEB, 0x33,
0xA0, 0xF4, 0xA1, 0x39, 0x45, 0xD8, 0x98, 0xC2, 0x96, 0x4F, 0xE3, 0x42,
0xE2, 0xFE, 0x1A, 0x7F, 0x9B, 0x8E, 0xE7, 0xEB, 0x4A, 0x7C, 0x0F, 0x9E,
0x16, 0x2B, 0xCE, 0x33, 0x57, 0x6B, 0x31, 0x5E, 0xCE, 0xCB, 0xB6, 0x40,
0x68, 0x37, 0xBF, 0x51, 0xF5
};

generator point length is 65 instead of 64

Thanks,
Matt

Looking at the example in the other forum thread and using the secp256k1 in the same process i followed it looks as though the first byte of the generator_point array is deleted (0x04). In my generated array i also have this same starting byte. Is there a reason this is deleted?

I believe that byte specifies whether the data is raw or compressed. I presume as the driver only supports raw there is no need for this byte.

Regards,

Ian.

I believe that byte specifies whether the data is raw or compressed. I presume as the driver only supports raw there is no need for this byte.

Regards,

Ian.